<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 2, 2014 at 8:57 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"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Wed, Jul 2, 2014 at 6:35 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-02 08:50, Isaac Bennetch a écrit :<br>
<div><div>><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" target="_blank">marc@infomarc.info</a><br>
>>> <mailto:<a href="mailto:marc@infomarc.info" target="_blank">marc@infomarc.info</a>>> wrote:<br>
>>><br>
>>> Le 2014-07-01 08:43, Chirayu Chiripal a écrit :<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On Thu, Jun 26, 2014 at 8:30 PM, Isaac Bennetch<br>
>>> <<a href="mailto:bennetch@gmail.com" target="_blank">bennetch@gmail.com</a> <mailto:<a href="mailto:bennetch@gmail.com" target="_blank">bennetch@gmail.com</a>><br>
>>> > <mailto:<a href="mailto:bennetch@gmail.com" target="_blank">bennetch@gmail.com</a> <mailto:<a href="mailto:bennetch@gmail.com" target="_blank">bennetch@gmail.com</a>>>> wrote:<br>
>>> ><br>
>>> > Hi,<br>
>>> ><br>
>>> > Marc has already provided excellent answers to most of this,<br>
>>> but see<br>
>>> > below:<br>
>>> ><br>
>>> > On 6/26/14 6:25 AM, Chirayu Chiripal wrote:<br>
>>> > > On Thu, Jun 26, 2014 at 3:31 PM, 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>
>>> > <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>>><br>
>>> > > <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>><br>
>>> <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>
>>> > > Le 2014-06-25 06:23, Chirayu Chiripal a écrit :<br>
>>> > > > Hi,<br>
>>> > > > Feature Request Link:<br>
>>> > > > <a href="http://sourceforge.net/p/phpmyadmin/feature-requests/637/" target="_blank">http://sourceforge.net/p/phpmyadmin/feature-requests/637/</a><br>
>>> > > ><br>
>>> > > > I am bit confused that what does this RFE is all<br>
>>> about. Here<br>
>>> > is my<br>
>>> > > doubt:<br>
>>> > > ><br>
>>> > > > 1] Does this feature requests says that if a field has a<br>
>>> > "prepend"<br>
>>> > > input<br>
>>> > > > transformation plugin with prepend text as "phpMyAdmin<br>
>>> " then on<br>
>>> > > insert<br>
>>> > > > page if someone enters into this field "Bringing MySQL to<br>
>>> > the web" and<br>
>>> > > > when a row is inserted then it should insert "phpMyAdmin<br>
>>> > Bringing<br>
>>> > > MySQL<br>
>>> > > > to the web" into the database.<br>
>>> > > ><br>
>>> > > > OR it requires something else?<br>
>>> > ><br>
>>> > > Hi Chirayu,<br>
>>> > > the example you mention is correct, but this feature request<br>
>>> > is much<br>
>>> > > more than that. Look at the comment from Garvin in the RFE.<br>
>>> > ><br>
>>> > > In reality, we don't have to code a credit card validation,<br>
>>> > for example;<br>
>>> > > we just have to provide the mechanism by which someone can<br>
>>> > code their<br>
>>> > > own credit card validation and apply it to the input field.<br>
>>> > ><br>
>>> > ><br>
>>> > > In my proposal, I also gave an example of regex validation<br>
>>> plugin i.e.<br>
>>> > > if some invalid data is inserted then that plugin can<br>
>>> replace that<br>
>>> > > invalid data with some other value (which would be given in<br>
>>> plugin<br>
>>> > > options) and if data is valid then it should go as it is. I<br>
>>> am not<br>
>>> > sure<br>
>>> > > about canceling the insert with error message right now but<br>
>>> it can be<br>
>>> > > done like by setting value for invalid data in plugin option as<br>
>>> > NULL for<br>
>>> > > not null column which would automatically fail the insert or<br>
>>> in the<br>
>>> > > plugin itself if validation fails then it could throw a<br>
>>> error and stop<br>
>>> > > the execution of the script itself or we can have a boolean<br>
>>> & error<br>
>>> > > variable in transformation plugin which would be checked before<br>
>>> > > insert/update and take actions likewise.<br>
>>> ><br>
>>> > I think rather than waiting until submission and trying to<br>
>>> make the<br>
>>> > INSERT fail, we should do any validation client side (through<br>
>>> JavaScript<br>
>>> > so when the field loses focus, we validate and display a<br>
>>> non-intrusive<br>
>>> > message explaining that it's invalid). Does this help?<br>
>>> ><br>
>>> ><br>
>>> > I recently noticed that in "transformation" column of<br>
>>> "pma__column_info"<br>
>>> > table the name of transformation is stored something like this:<br>
>>> > "image_jpeg__inline.inc.php" rather than<br>
>>> "image_jpeg__inline.class.php"<br>
>>> > i.e. extension ".class.php" is replaced with ".inc.php" while storing<br>
>>> > and it is reversed while fetching. Is there any particular reason for<br>
>>> > doing this?<br>
>>><br>
>>> Yes, the reason is backward compatibility, but maybe it's time to do a<br>
>>> radical move about this.<br>
>>><br>
>>> In pma__column _info, the transformation column contains a string ending<br>
>>> with .inc.php which, in older versions, matched the file name.<br>
>>><br>
>>> It would be cleaner to invent some code that describes each<br>
>>> transformation, but then all users would have to redefine their<br>
>>> transformations, unless we provide them with some .sql file to run, that<br>
>>> would do the conversion.<br>
>>><br>
>>> If we do a conversion, it would mean that a pmadb would not be backward<br>
>>> compatible with older phpMyAdmin versions.<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>
</div></div>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></blockquote><div><br></div></div></div><div>We can provide one SQL script to upgrade and I'll have a look how this PMA_getRelationsParamDiagnostic() works.<span class=""><font color="#888888"><br>
</font></span></div></div></div></div></blockquote><div><br></div><div>Please, review the work I have done so far: <a href="https://github.com/D-storm/phpmyadmin/tree/FR-637">https://github.com/D-storm/phpmyadmin/tree/FR-637</a>. So that I can come to know if I am missing something or not. Tasks to be done yet includes: Mechanism to change input fields & One plugin to demonstrate/test this and fix failing testcases.<br>
<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><span class=""><font color="#888888"><br>
</font></span></div><span class=""><font color="#888888"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><font color="#888888"><br>
--<br>
Marc Delisle | phpMyAdmin<br>
</font></span><div><div><br>
</div></div></blockquote></font></span></div><div class=""><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></div>
</blockquote></div><br></div></div>