I am wondering if it's possible with a plugin to alter a table.
My question is not about a technical problem to do this, but about risk.
If I alter the table (=> adding columns & indexes), I'm not sure about the compatibility with next release of piwigo.
Taking an example :
ALTER TABLE `piwigo_history` ADD COLUMN `testgbl` char(1) ASCII NOT NULL AFTER `image_type`, ADD INDEX `gblindex`(`testgbl`);
Tomorrow, if piwigo needs to add the 'muchmuch' column in the history table, how the upgrade will do ?
Does will it work ? Does will it stop the piwigo upgrade process ?
I'm not sure it's a good idea to do this, but having a column directly on the table is better for performances than making a join...
Offline
grum wrote:
I am wondering if it's possible with a plugin to alter a table.
Currently, there are plugins doing this:
* [extension by P@t] Additional Pages (add a value in the history.section enum field)
* [extension by P@t] Lightbox (add a column in the history table)
* [extension by P@t] Has High (add a value in the history.section enum field)
* [extension by mistic100] Colored Tags (add a column in the tags table)
* [extension by rub] Web services statistics (add a value in the history.section enum field)
* [extension by P@t] Most Commented (add a value in the history.section enum field)
* [extension by rvelices] RV Maps & Earth (add columns in the images table)
(I find them after a "svn checkout http://piwigo.org/extensions; find extensions -name maintain.inc.php | xargs grep -i alter")
For my first plugin [extension by plg] Community, I've created a dedicated table, but I could have added a column in the users_infos table. I just got inspiration from [extension by Eric] UserAdvManager.
I think that adding a column has no consequence on upgrades. We don't check the list of columnsin order to stop the process if we get too many columns (but we list the existing columns to "discover" which version is running).
I was not aware that so many plugins were modifying the history.section column. And this is a problem. It will clearly break if the next upgrade updates the column. We should think of another way to list the possible sections than an enum field. I'll open a topic for this specific problem and invite plugin authors.
Offline
If possible, I create specifics tables for the plugins.
Just here, I'm searching to improve performances for some AStat requests, and I explore all the possibilities (uses specifics tables or alter the history table....).
Offline
For the plugin [extension by ddtddt] Meta I add a column to the table *_categories.
This plant is adding image to users who wrote in this table.
It is better, it seems to me, not to add a column in existing table
Offline
plg wrote:
I was not aware that so many plugins were modifying the history.section column. And this is a problem. It will clearly break if the next upgrade updates the column. We should think of another way to list the possible sections than an enum field. I'll open a topic for this specific problem and invite plugin authors.
[Forum, topic 15323] [coding] history.section, enum type or foreign key
Offline