Le 2014-07-04 17:41, Isaac Bennetch a écrit :

>
>
> On 7/2/14, 9:05 AM, Marc Delisle wrote:
>> Le 2014-07-02 08:50, Isaac Bennetch a écrit :
>>>
>>>
>>> On 7/2/14, 8:31 AM, Marc Delisle wrote:
>>>> Le 2014-07-01 09:26, Chirayu Chiripal a écrit :
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 1, 2014 at 6:43 PM, Marc Delisle <marc@infomarc.info
>>>>> <mailto:marc@infomarc.info>> wrote:
>>>>>
>>>>>     Le 2014-07-01 08:43, Chirayu Chiripal a écrit :
>
> ...
>
>>>>>
>>>>>
>>>>> Well, to separate the input & output transformations I would be moving
>>>>> current transformation plugins into a new output sub-directory (as
>>>>> mentioned in my blog), which would also break the backward
>>>>> compatibility. Also as 2 new columns are being added to pma__column_info
>>>>> which would also require users to upgrade their tables for
>>>>> transformations to work. So, I think its time to remove that backward
>>>>> compatibilty hack.
>>>>
>>>> Fine with me, but please confirm with your mentor.
>>>
>>> It's fine with me as well. I wonder if we might easily provide a way to
>>> automatically update (for instance detect the missing columns and prompt
>>> the user to automatically upgrade to the new structure, or detect the
>>> .inc.php in pma__column_info and automatically replace the data in the
>>> column with .class.php), but I'm not immediately sure whether such check
>>> is really necessary. Such checks shouldn't require much overhead to
>>> test, but add complexity.
>>>
>>> Ideally, we could force the user to run once a script (such as
>>> upgrade.php) when first installing/upgrading, but I haven't yet thought
>>> of a good way to run it on first install and never again (mainly since
>>> we can't depend on being able to write to the phpMyAdmin Configuration
>>> Storage or file system in every installation).
>>>
>>> Any thoughts about this from the rest of the team?
>>
>> I had a look at we did for another similar case.
>>
>> In libraries/relation.lib.php, PMA_getRelationsParamDiagnostic(), we do
>> some verifications, then display this if needed: "Please see the
>> documentation on how to update your column_comments table."
>>
>> Have a look in doc/config.rst, searching for "to update your PRE-2.5.0",
>> to see the explanation for updating
>
>
> This is not bad, but -- remember that I haven't actually tried to code
> what I'm about to describe so I could be wrong -- it seems it wouldn't
> be much more work from this to actually update the table structure for
> the user. If in PMA_getRelationsParamDiagnostic() we can detect when the
> table structure is outdated and display a message, can't we just as
> easily run the query to update the table? We can't just automatically
> add a table (because the table has to be added to config.inc.php) or
> create the entire database (because we don't know the username and
> password the user wishes to use), but it seems the update could be done
> without needing to involve the user. Remember, many users don't like to
> read the documentation, so the more we can do without involving them,
> the better the user experience will be.
>
> Now, whether people agree with me and whether it actually make sense to
> do that are two other matters, but hopefully at least my statement makes
> some sense.
>
> Regards,
> ~isaac

Indeed it makes sense to update the table structure for the users.

--
Marc Delisle | phpMyAdmin