<div dir="ltr">Hello Isaac Sir,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 6, 2014 at 5:14 PM, Chirayu Chiripal <span dir="ltr"><<a href="mailto:chirayu.chiripal@gmail.com" target="_blank">chirayu.chiripal@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 dir="ltr">Hi,<br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">
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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<div><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" target="_blank">marc@infomarc.info</a><br>
</div><div>> <mailto:<a href="mailto:marc@infomarc.info" target="_blank">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" target="_blank">marc@infomarc.info</a><br>
> <mailto:<a href="mailto:marc@infomarc.info" target="_blank">marc@infomarc.info</a>><br>
</div><div>> > <mailto:<a href="mailto:marc@infomarc.info" target="_blank">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info" target="_blank">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" target="_blank">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info" target="_blank">marc@infomarc.info</a>><br>
</div><div><div>> > <mailto:<a href="mailto:marc@infomarc.info" target="_blank">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info" target="_blank">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></div><div>Are constraints such as foreign key always exported as separate queries?<br><br></div></div></div></div></blockquote>
<div>I have almost completed this feature request, currently I am adding few more test cases, updating documentation and will fix few minor known issues. Meanwhile, if you get time to review the code, you can see the code here: <a href="https://github.com/D-storm/phpmyadmin/tree/FR-759">https://github.com/D-storm/phpmyadmin/tree/FR-759</a>. After completing the work what I have mentioned above, I will squash the commits then I'll check travis, coveralls, and scrutinizer reports and will open up a pull request. I will complete this by today itself.<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><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></div>
</blockquote></div><br></div></div>