<div dir="ltr">Hi,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 3, 2014 at 7:43 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class=""><br>
On 5/25/14 9:18 AM, Chirayu Chiripal wrote:<br>
> On Sun, May 25, 2014 at 4:05 AM, Marc Delisle <<a href="mailto:marc@infomarc.info">marc@infomarc.info</a><br>
</div><div class="">> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>>> wrote:<br>
><br>
>     Le 2014-05-24 14:52, Chirayu Chiripal a écrit :<br>
>     > Hi,<br>
>     ><br>
>     > On Fri, May 23, 2014 at 12:52 AM, Marc Delisle <<a href="mailto:marc@infomarc.info">marc@infomarc.info</a><br>
>     <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>><br>
</div><div class="">>     > <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>>>> wrote:<br>
>     ><br>
>     >     Chirayu Chiripal a écrit :<br>
>     >     > On Fri, May 23, 2014 at 12:35 AM, Marc Delisle<br>
>     <<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>><br>
</div><div><div class="h5">>     >     <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>>>> wrote:<br>
>     >     ><br>
>     >     >> Chirayu Chiripal a écrit :<br>
>     >     >>> Hi,<br>
>     >     >>><br>
>     >     >>> While analyzing the current behavior of export feature, few<br>
>     >     doubts has<br>
>     >     >>> arisen in my mind regarding it. In sql_export.png, There<br>
>     are two<br>
>     >     export<br>
>     >     >>> buttons, button 1 & button 2 respectively. When exporting<br>
>     using<br>
>     >     Button 1<br>
>     >     >>> shown in sql_export.png, the resulting sql file had all<br>
>     the rows (20<br>
>     >     >> rows)<br>
>     >     >>> present in the table (See QA_4_2_Button_1_export.sql)<br>
>     whereas when<br>
>     >     >> Button 2<br>
>     >     >>> was used then only the rows (10 rows) displayed in results<br>
>     >     according to<br>
>     >     >> the<br>
>     >     >>> LIMIT condition in the query were in the sql file (See<br>
>     >     >>> QA_4_2_Button_2_export.sql). Is this the correct behavior or<br>
>     >     both should<br>
>     >     >>> have generated identical sql export file?<br>
>     >     >>><br>
>     >     >>> SQL query which was used: SELECT * FROM `abcd` WHERE 1<br>
>     limit 10<br>
>     >     >>><br>
>     >     >> Button 1 means to export the rows that you have selected<br>
>     via each<br>
>     >     row's<br>
>     >     >> checkbox.<br>
>     >     >><br>
>     >     >> --<br>
>     >     >> Marc Delisle (phpMyAdmin)<br>
>     >     >><br>
>     >     ><br>
>     >     > What if I didn't selected any rows?<br>
>     >     ><br>
>     >     > IMHO, In this case it should not export rows which are not<br>
>     in the<br>
>     >     resultset<br>
>     >     > of the query but it is exporting all the rows of the table.<br>
>     ><br>
>     >     Correct, it should not export anything.<br>
>     ><br>
>     >     --<br>
>     >     Marc Delisle (phpMyAdmin)<br>
>     ><br>
>     ><br>
>     ><br>
>     > Currently, there is no SQL Export for queries involving multiple<br>
>     tables<br>
>     > such as join query. So, does that mean aliases is to be considered<br>
>     only<br>
>     > in SELECT statements involving one table? or Am I missing<br>
>     something here?<br>
><br>
>     Indeed, exporting a join query makes no sense to me.<br>
><br>
><br>
>     --<br>
>     Marc Delisle | phpMyAdmin<br>
><br>
> A table maybe having triggers present, so while exporting even old<br>
> column and table names have to be replaced by alias which is a bit<br>
> problem here because current SQL parser does not provide information<br>
> about aliases in such cases with PMA_SQP_analyze(). Maybe some of these<br>
> approaches can be used:<br>
><br>
> 1) We can get token array by using PMA_SQP_parse() to get tokens which<br>
> have to processed which is bit problematic because result of<br>
> PMA_SQP_parse() detects 'TRIGGER', 'BEFORE' few keywords used in 'CREATE<br>
> TRIGGER' statement as an identifier rather than keyword and it becomes<br>
> difficult to decide whether it was used as column or table name or it is<br>
> used as keyword. Maybe we can first look for SELECT, INSERT, DELETE,<br>
> UPDATE, SET, NEW, OLD keywords first then consider identifier followed<br>
> by them. I am not sure whether this kind of approach can give us correct<br>
> results every time.<br>
><br>
> 2) Or we can separate different SQL statements such as SELECT, INSERT,<br>
> SET etc. inside create query of trigger into separate queries and then<br>
> parse them using PMA_SQP_analyze() and then substitute aliases. I have<br>
> no idea how to separate them as trigger body may have various constructs<br>
> present in them such as loops, if-then-else conditions etc.<br>
><br>
> Any other suggestions about how to extract column and table names from<br>
> the create queries of trigger?<br>
<br>
</div></div>I'll admit that PMA_SQP_parse() isn't something I'm very familiar with,<br>
so I welcome input from others, but I do have two thoughts to share.<br>
<br>
First, if we risk not doing something completely and correctly, we<br>
should either warn the user or in other ways help the user know to<br>
double-check their data. In this case, when a trigger is detected, a<br>
message could be displayed such as "It appears your table uses triggers;<br>
alias export may not work reliably in all cases." However, of course I<br>
prefer if we can find a solution that works correctly in all cases :)<br>
<br>
Secondly, it seems to me your first solution is better than the second<br>
option. Forgive me for not having tested it myself, but in general a<br>
properly-formatted query will escape table and database names with<br>
backticks ` so that keywords are easily identified as those without<br>
surrounding backticks. Does that not help us in this instance?<br></blockquote><div><br></div><div>Are constraints such as foreign key always exported as separate queries?<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=""><br>
> --<br>
> 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>
><br>
><br>
</div></blockquote></div></div></div>