<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 5, 2014 at 4:26 PM, Marc Delisle <span dir="ltr"><<a href="mailto:marc@infomarc.info" target="_blank">marc@infomarc.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le 2014-07-04 17:41, Isaac Bennetch a écrit :<br>
<div><div class="h5">><br>
><br>
> On 7/2/14, 9:05 AM, Marc Delisle wrote:<br>
>> Le 2014-07-02 08:50, Isaac Bennetch a écrit :<br>
>>><br>
>>><br>
>>> On 7/2/14, 8:31 AM, Marc Delisle wrote:<br>
>>>> Le 2014-07-01 09:26, Chirayu Chiripal a écrit :<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Tue, Jul 1, 2014 at 6:43 PM, Marc Delisle <<a href="mailto:marc@infomarc.info">marc@infomarc.info</a><br>
>>>>> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>>> wrote:<br>
>>>>><br>
>>>>>     Le 2014-07-01 08:43, Chirayu Chiripal a écrit :<br>
><br>
> ...<br>
><br>
>>>>><br>
>>>>><br>
>>>>> Well, to separate the input & output transformations I would be moving<br>
>>>>> current transformation plugins into a new output sub-directory (as<br>
>>>>> mentioned in my blog), which would also break the backward<br>
>>>>> compatibility. Also as 2 new columns are being added to pma__column_info<br>
>>>>> which would also require users to upgrade their tables for<br>
>>>>> transformations to work. So, I think its time to remove that backward<br>
>>>>> compatibilty hack.<br>
>>>><br>
>>>> Fine with me, but please confirm with your mentor.<br>
>>><br>
>>> It's fine with me as well. I wonder if we might easily provide a way to<br>
>>> automatically update (for instance detect the missing columns and prompt<br>
>>> the user to automatically upgrade to the new structure, or detect the<br>
>>> .inc.php in pma__column_info and automatically replace the data in the<br>
>>> column with .class.php), but I'm not immediately sure whether such check<br>
>>> is really necessary. Such checks shouldn't require much overhead to<br>
>>> test, but add complexity.<br>
>>><br>
>>> Ideally, we could force the user to run once a script (such as<br>
>>> upgrade.php) when first installing/upgrading, but I haven't yet thought<br>
>>> of a good way to run it on first install and never again (mainly since<br>
>>> we can't depend on being able to write to the phpMyAdmin Configuration<br>
>>> Storage or file system in every installation).<br>
>>><br>
>>> Any thoughts about this from the rest of the team?<br>
>><br>
>> I had a look at we did for another similar case.<br>
>><br>
>> In libraries/relation.lib.php, PMA_getRelationsParamDiagnostic(), we do<br>
>> some verifications, then display this if needed: "Please see the<br>
>> documentation on how to update your column_comments table."<br>
>><br>
>> Have a look in doc/config.rst, searching for "to update your PRE-2.5.0",<br>
>> to see the explanation for updating<br>
><br>
><br>
> This is not bad, but -- remember that I haven't actually tried to code<br>
> what I'm about to describe so I could be wrong -- it seems it wouldn't<br>
> be much more work from this to actually update the table structure for<br>
> the user. If in PMA_getRelationsParamDiagnostic() we can detect when the<br>
> table structure is outdated and display a message, can't we just as<br>
> easily run the query to update the table? We can't just automatically<br>
> add a table (because the table has to be added to config.inc.php) or<br>
> create the entire database (because we don't know the username and<br>
> password the user wishes to use), but it seems the update could be done<br>
> without needing to involve the user. Remember, many users don't like to<br>
> read the documentation, so the more we can do without involving them,<br>
> the better the user experience will be.<br>
><br>
> Now, whether people agree with me and whether it actually make sense to<br>
> do that are two other matters, but hopefully at least my statement makes<br>
> some sense.<br>
><br>
> Regards,<br>
> ~isaac<br>
<br>
</div></div>Indeed it makes sense to update the table structure for the users.<br></blockquote><div><br></div><div>Hello,<br></div><div>I have added auto detection and upgrade logic for pma__column_info table. What I did is that, I created one upgrade_column_info_4_3_0+.sql file under examples directory for the manual/auto upgrade. In PMA_checkRelationsParam(), if pma__column_info table is present then we check whether it has input transformations columns or not. If they are present then there is no need to upgrade otherwise we try to silently upgrade the table for user by executing the upgrade_column_info_4_3_0+.sql file. The overhead will be of 1 query which is executed once per login for checking columns. <br>
<br>The feature seems complete except few documentation work which will be added soon. Meanwhile, you can review the work here: <a href="https://github.com/D-storm/phpmyadmin/tree/FR-637">https://github.com/D-storm/phpmyadmin/tree/FR-637</a><br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><font color="#888888"><br>
--<br>
Marc Delisle | phpMyAdmin<br>
</font></span><div class=""><div class="h5"><br></div></div></blockquote></div><br>-- <br><div dir="ltr">Regards,<br>Chirayu Chiripal<br>phpMyAdmin Intern - Google Summer of Code 2014<br><a href="https://chirayuchiripal.wordpress.com/" target="_blank">https://chirayuchiripal.wordpress.com/</a><br>
</div>
</div></div>