> 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
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
