Le 2012-07-01 05:16, Alex Marin a écrit :
On Sat, Jun 30, 2012 at 10:38 PM, Marc Delisle marc@infomarc.info wrote:
Alex, about backward compatibility (BC), it's now apparent that choosing to put a script name inside pma_column_info.transformation was a decision that has shortcomings.
Maybe there should be some kind of neutral string there, that is not a script name nor a class name, but just indicates the kind of transformation. Then, the code would map this string to the exact script to call.
Ok, that sounds good.
Anyway, we have to decide if the BC will be done by some permanent code in the transformation logic, or via a conversion script that the user has to run.
I would say that although the conversion script is easier to implement, from the users point of view, they would have to make an additional step to maintain their old databases (at first it won't work and then they would have to read about it).
Indeed, an automatic solution is better; hopefully, the conversion would take place only the first time old values are detected.
Maybe, a version number in pma_column_info would help, to see if conversion is needed.
When getting a new release of PMA, users can keep their old config file. Would that mean that some users will have a version number and others won't?
Version number in pma_column_info was a suggestion to detect a needed change, but it implies adding a column to this table and this cannot be done with the limited privileges that a "normal" control user has (see examples/create_tables.sql). So, I'm no longer sure we should use a version number.
By permanent code do you mean that the old format will be kept in pma_column_info for existing transformations and then treated differently depending on a version number?
By permanent code, I meant code that runs every time, instead of asking the phpMyAdmin installer to run a conversion script.
What happens when a user modifies an existing transformation, will the same old version be used?
We are not responsible for code changes in phpMyAdmin.