<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 9, 2014 at 10:58 PM, Isaac Bennetch <span dir="ltr"><<a href="mailto:bennetch@gmail.com" target="_blank">bennetch@gmail.com</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"><div class=""><br>
<br>
On 7/9/14, 1:22 PM, Marc Delisle wrote:<br>
> Le 2014-07-09 11:34, Isaac Bennetch a écrit :<br>
>> Hello,<br>
>><br>
>> In the course of my testing the new input transformation feature, I've<br>
>> encountered some trouble that Chirayu is unable to reproduce. We've had<br>
>> a bit of discussion privately about it, but wanted to move discussion<br>
>> back to the mailing list.<br>
>><br>
>> Note that running his branch[1] will change your pma__column_info table<br>
>> structure; so you may wish to back it up for testing purposes.<br>
>><br>
>> The problem at the moment is the automatic table upgrade feature. What<br>
>> is supposed to happen is that, when logging in,<br>
>> PMA_checkRelationsParam() verifies that the correct table structure<br>
>> exists for pma__column_info. If it doesn't, it attempts to run<br>
>> ./examples/upgrade_column_info_4_3_0+.sql (after substituting the<br>
>> correct database and table names if needed). This is all quite good.<br>
><br>
> On my Debian wheezy 64-bit machine (7.5), the auto upgrade went fine. Do<br>
> you have a control user explicitely defined?<br>
<br>
</div>Thanks for checking. Yes, I do. I'm also on Wheezy, but 32-bit. I'll<br>
have to do some further testing, perhaps tomorrow.<br></blockquote><div> </div></div>Hi,<br><br></div><div class="gmail_extra">I intentionally manipulated intermediate queries and made them to fail to reproduce this problem and noticed few things.<br>
 <br></div><div class="gmail_extra">1) multi_query returns the result of the first query i.e. in our case 'USE `phpmyadmin`'. If this first query is executed successfully and if next alter table query fails then it will return true causing the problem you have mentioned. So, we have to loop through all query results and return true only if all query gets successfully executed. After first failure, further queries are skipped.<br>
<br></div><div class="gmail_extra">2) This might not be the reason causing this issue but this needs to be fixed before this issue can be fixed. See [1] & [2]. One of those is already fixed in master. I am not sure whether fix should go in QA_4_2 or master.<br>
<br></div><div class="gmail_extra">3) I don't know why $GLOBALS['dbi']->storeResult($GLOBALS['controllink']) is returning false everytime for all the queries in the loop. This means we can't fetch error or result of each query.<br>
<br>Note: I also tried using mysqli_multi_query(), mysqli_store_result(), 
mysqli_use_result() functions with link as $GLOBALS['controllink'] but 
result was same. So, it may be the problem with controllink or with 
php/mysql itself.<br><br></div><div class="gmail_extra">**Possible Workaround:** However number of result sets returned are equal to the queries executed so we can count it in loop and see if it matches the total (we have to count queries in sql file and use that in code which means if queries are added/deleted from file then we have to change the total in code also).<br>
<br>Also, as queries may fail in between after executing some of them so we need to combine the alter queries into single query to ensure that either both columns are added or none.<br><br>Also, we need to move the update queries before alter queries (they should be done at last) to ensure that current data is updated before altering the table to avoid a case when alter query gets executed and update query fails leaving the old transformations unusable as any further logins will see that columns are present and will not update it anymore.<br>
<br></div><div class="gmail_extra">After moving update query before alter query we need to change our update query because currently we are prepending 'output/' to plugins using NOT IN clause and if after executing update query, following alter query fails then next time it will try to update then it will change the column content to something like this 'output/output/' (multiple prepend). So, instead of NOT IN we need to use IN clause.<br>
<br></div><div class="gmail_extra">Doing these changes will make sure that old transformation data is updated before altering table and multiple update queries does not produce any side effects.<br><br></div><div class="gmail_extra">
Is this good enough?<br></div><div class="gmail_extra"><br>[1] : <a href="https://github.com/phpmyadmin/phpmyadmin/blob/QA_4_2/libraries/DatabaseInterface.class.php#L2164">https://github.com/phpmyadmin/phpmyadmin/blob/QA_4_2/libraries/DatabaseInterface.class.php#L2164</a><br>
[2] : <a href="https://github.com/phpmyadmin/phpmyadmin/blob/QA_4_2/libraries/DatabaseInterface.class.php#L2176">https://github.com/phpmyadmin/phpmyadmin/blob/QA_4_2/libraries/DatabaseInterface.class.php#L2176</a><br clear="all">
</div><div class="gmail_extra"><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>