Join GitHub today
plugin API: Improve plugins' ability to indicate custom DB tables #317
Create a new array structure (or something like that) in the introspect-method to let plugins declare which tables they create with which structure. Allow to use specific version numbers to later upgrades to the schema (staticpages is a good example).
Create a new plugin API method like "init_tables()" which replicate the current custom functionality in plugins that use their "db_version" strings (use db_version for each plugin that supports custom table structure?).
Add a version check to only use those new methods when s9y 2.1+ is used, so that those plugins can be upgraded but will stil work on older environments for the time being.
referenced this issue
Mar 9, 2015
I added a feature branch containing a first proposal for that feature: https://github.com/s9y/Serendipity/tree/feature_dbpluginapi
@ddeimeke Sorry. You need to check out the "feature_dbpluginapi" branch... however, this does not contain the other master changes. So you shouldn't use that on your live blog, but install a fresh one with that branch.
Or wait until @onli approves so that we can merge it with master for you to test with.
Or, you could manually copy over those files:
to your current blog...
I think that is too soon. The api is not ready - we need a (basic) mechanism to upgrade a database. And I don't think I checked, but we need to make sure the install-function is executed afterwards, to make it possible to add manual indexes. Also, what is missing is to support db_schema, to make that work properly with different databases.
I'll add another comment to your commit itself.
No offense taken, nor intented by my response. I appreciate your input. I'd like to hear @ddeimeke chime in, who was leading the charge of wanting this feature. :-)
I think otherwise; if we have a feature that deals with stale tables, we really need to make it work properly, and take the real-world scenario into account. If we only supported the API way and not look at existing plugins, that wouldn't benefit the users (for which we want such a feature).
It would not be; for all future plugins, the "tables" api mechanism would meant to be used. I wouldn't plan on updating that array ever.
Currently I think we have two issues mixed up with each other: One is the maintenance option, and one is the DB plugin API. While I think that the DB plugin API needs more improvement, I do like the maintenance task at this point, and that it takes care of all tables.
I can surely hold off on merging the code if you want to improve the DB plugin API at first.
I would also be fine with dropping $legacy_plugintables, if we update ALL spartacus plugins to support the 'tables' mechanism. But that seems like a whole lot of work, because very many plugins use different ways of initializing the database. I'd rather like to make a "fresh" start for new plugins that should use this "tables" feature, and not backport it to all old plugins because it could really break; and we'd have to redundantly always have a fall-back way for serendipity < 2.1 so that plugins would work.
This is why I currently honestly think the $legacy_plugintables approach is the pragmatic, workable way...
@garvinhicking Currently it is difficult to follow, because you quote a post, which I am not able to see.
Coming from the maintenance perspective:
My very pragmatic approach would be filling a "transition table" which includes a mapping between plugins and tables. This would be a one time effort.
Future plugins or future plugin versions could register their needs in that table on their own.
A second table would be needed to classify the plugins as part of the core.
Last step would be a check. Show all plugins which are disabled and not part of the core. Check with the database which tables are affected (and exclusively used by disabled plugins). Offer to delete the plugin from disk and the table from the database.
I don't know enough about internal structures to know if that is possible.
(Your idea goes a bit into the currently implemented direction; of course with the "nasty" sideeffects that onli mentions, because it's basically redundancy right now)
Maybe it would be great if you could copy over the files I mentioned in the post earlier to your current blog (make a backup of the files you currently use) to see the current implementation of it. It only affects the maintenance section, so that shouldn't interfer. (If you can create a clone of your blog, that would be best though, if you have means to easily duplicate your blog with files + database)
I think part of my doubts is that this is not totally the feature I wanted ;) I understood we wanted to list plugin-tables, not potentially all of them. See also Dirks last description :)
Yes, right. That is unfortunate :/
That is right, Dirk basically described the $legacy_plugins-array. So, if that is to stay, maybe we can hide that at least? It could go include/tpl/ or include/db/ or something like that and only be included here?
And then we could maybe break that out of the db-plugin-api and have that feature already, while having time to improve the API separately? Maybe that is not really needed, but I'm not sure how difficult that will be to do right.