> 1) It requires its own db table instead of making use of the configs
> table. This is different than we thought about for plugins but perhaps
> there's no way to shoe-horn what we want into a strict no-new-db-schema
> mold? itbegins, I'm curious what you guys have done in zikula for
> plugins storing data since you've got a longer history and greater need
> for doing this well.
Almost all our Zikula modules use their own data table - for large amounts of data it wouldn't be practical to shoe horn it into an existing system. We do provide a central module variables storage table, so for example you can do something like ModuleSetVar('MyModule', 'MyName', 'MyValue'); and the obvious extension for getting variables. These are serialized and stored in a central table, and are good for basic configuration, but not actual data storage. A retrieval of one module variable automatically caches all the module variables for that module, so repeated requests don't incur the DB query penalty.
I would advise that any serious module storing its own data uses a schema of its own. Anything else is likely to introduce unnecessary complication/indirection or problematic performance. Having said that, I don't have much of an idea what the functionality of the proposed plugin is, so I can't comment specifically :)
Simon
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
