<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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 class="h5">><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>
>>>     > On Thu, Jun 26, 2014 at 8:30 PM, Isaac Bennetch<br>
>>>     <<a href="mailto:bennetch@gmail.com">bennetch@gmail.com</a> <mailto:<a href="mailto:bennetch@gmail.com">bennetch@gmail.com</a>><br>
>>>     > <mailto:<a href="mailto:bennetch@gmail.com">bennetch@gmail.com</a> <mailto:<a href="mailto:bennetch@gmail.com">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">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>><br>
>>>     >     <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>>><br>
>>>     >     > <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a> <mailto:<a href="mailto:marc@infomarc.info">marc@infomarc.info</a>><br>
>>>     <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>
>>>     >     >     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>We can provide one SQL script to upgrade and I'll have a look how this PMA_getRelationsParamDiagnostic() works.<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">

<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>