On Wed, Jul 2, 2014 at 6:35 PM, Marc Delisle <marc@infomarc.info> wrote:

Le 2014-07-02 08:50, Isaac Bennetch a écrit :

>
>
> On 7/2/14, 8:31 AM, Marc Delisle wrote:
>> Le 2014-07-01 09:26, Chirayu Chiripal a écrit :
>>>
>>>
>>>
>>> On Tue, Jul 1, 2014 at 6:43 PM, Marc Delisle <marc@infomarc.info
>>> <mailto:marc@infomarc.info>> wrote:
>>>
>>>     Le 2014-07-01 08:43, Chirayu Chiripal a écrit :
>>>     >
>>>     >
>>>     >
>>>     > On Thu, Jun 26, 2014 at 8:30 PM, Isaac Bennetch
>>>     <bennetch@gmail.com <mailto:bennetch@gmail.com>
>>>     > <mailto:bennetch@gmail.com <mailto:bennetch@gmail.com>>> wrote:
>>>     >
>>>     >     Hi,
>>>     >
>>>     >     Marc has already provided excellent answers to most of this,
>>>     but see
>>>     >     below:
>>>     >
>>>     >     On 6/26/14 6:25 AM, Chirayu Chiripal wrote:
>>>     >     > On Thu, Jun 26, 2014 at 3:31 PM, Marc Delisle
>>>     <marc@infomarc.info <mailto:marc@infomarc.info>
>>>     >     <mailto:marc@infomarc.info <mailto:marc@infomarc.info>>
>>>     >     > <mailto:marc@infomarc.info <mailto:marc@infomarc.info>
>>>     <mailto:marc@infomarc.info <mailto:marc@infomarc.info>>>> wrote:
>>>     >     >
>>>     >     >     Le 2014-06-25 06:23, Chirayu Chiripal a écrit :
>>>     >     >     > Hi,
>>>     >     >     > Feature Request Link:
>>>     >     >     > http://sourceforge.net/p/phpmyadmin/feature-requests/637/
>>>     >     >     >
>>>     >     >     > I am bit confused that what does this RFE is all
>>>     about. Here
>>>     >     is my
>>>     >     >     doubt:
>>>     >     >     >
>>>     >     >     > 1] Does this feature requests says that if a field has a
>>>     >     "prepend"
>>>     >     >     input
>>>     >     >     > transformation plugin with prepend text as "phpMyAdmin
>>>     " then on
>>>     >     >     insert
>>>     >     >     > page if someone enters into this field "Bringing MySQL to
>>>     >     the web" and
>>>     >     >     > when a row is inserted then it should insert "phpMyAdmin
>>>     >     Bringing
>>>     >     >     MySQL
>>>     >     >     > to the web" into the database.
>>>     >     >     >
>>>     >     >     > OR it requires something else?
>>>     >     >
>>>     >     >     Hi Chirayu,
>>>     >     >     the example you mention is correct, but this feature request
>>>     >     is much
>>>     >     >     more than that. Look at the comment from Garvin in the RFE.
>>>     >     >
>>>     >     >     In reality, we don't have to code a credit card validation,
>>>     >     for example;
>>>     >     >     we just have to provide the mechanism by which someone can
>>>     >     code their
>>>     >     >     own credit card validation and apply it to the input field.
>>>     >     >
>>>     >     >
>>>     >     > In my proposal, I also gave an example of regex validation
>>>     plugin i.e.
>>>     >     > if some invalid data is inserted then that plugin can
>>>     replace that
>>>     >     > invalid data with some other value (which would be given in
>>>     plugin
>>>     >     > options) and if data is valid then it should go as it is. I
>>>     am not
>>>     >     sure
>>>     >     > about canceling the insert with error message right now but
>>>     it can be
>>>     >     > done like by setting value for invalid data in plugin option as
>>>     >     NULL for
>>>     >     > not null column which would automatically fail the insert or
>>>     in the
>>>     >     > plugin itself if validation fails then it could throw a
>>>     error and stop
>>>     >     > the execution of the script itself or we can have a boolean
>>>     & error
>>>     >     > variable in transformation plugin which would be checked before
>>>     >     > insert/update and take actions likewise.
>>>     >
>>>     >     I think rather than waiting until submission and trying to
>>>     make the
>>>     >     INSERT fail, we should do any validation client side (through
>>>     JavaScript
>>>     >     so when the field loses focus, we validate and display a
>>>     non-intrusive
>>>     >     message explaining that it's invalid). Does this help?
>>>     >
>>>     >
>>>     > I recently noticed that in "transformation" column of
>>>     "pma__column_info"
>>>     > table the name of transformation is stored something like this:
>>>     > "image_jpeg__inline.inc.php" rather than
>>>     "image_jpeg__inline.class.php"
>>>     > i.e. extension ".class.php" is replaced with ".inc.php" while storing
>>>     > and it is reversed while fetching. Is there any particular reason for
>>>     > doing this?
>>>
>>>     Yes, the reason is backward compatibility, but maybe it's time to do a
>>>     radical move about this.
>>>
>>>     In pma__column _info, the transformation column contains a string ending
>>>     with .inc.php which, in older versions, matched the file name.
>>>
>>>     It would be cleaner to invent some code that describes each
>>>     transformation, but then all users would have to redefine their
>>>     transformations, unless we provide them with some .sql file to run, that
>>>     would do the conversion.
>>>
>>>     If we do a conversion, it would mean that a pmadb would not be backward
>>>     compatible with older phpMyAdmin versions.
>>>
>>>
>>> Well, to separate the input & output transformations I would be moving
>>> current transformation plugins into a new output sub-directory (as
>>> mentioned in my blog), which would also break the backward
>>> compatibility. Also as 2 new columns are being added to pma__column_info
>>> which would also require users to upgrade their tables for
>>> transformations to work. So, I think its time to remove that backward
>>> compatibilty hack.
>>
>> Fine with me, but please confirm with your mentor.
>
> It's fine with me as well. I wonder if we might easily provide a way to
> automatically update (for instance detect the missing columns and prompt
> the user to automatically upgrade to the new structure, or detect the
> .inc.php in pma__column_info and automatically replace the data in the
> column with .class.php), but I'm not immediately sure whether such check
> is really necessary. Such checks shouldn't require much overhead to
> test, but add complexity.
>
> Ideally, we could force the user to run once a script (such as
> upgrade.php) when first installing/upgrading, but I haven't yet thought
> of a good way to run it on first install and never again (mainly since
> we can't depend on being able to write to the phpMyAdmin Configuration
> Storage or file system in every installation).
>
> Any thoughts about this from the rest of the team?

I had a look at we did for another similar case.

In libraries/relation.lib.php, PMA_getRelationsParamDiagnostic(), we do
some verifications, then display this if needed: "Please see the
documentation on how to update your column_comments table."

Have a look in doc/config.rst, searching for "to update your PRE-2.5.0",
to see the explanation for updating.

We can provide one SQL script to upgrade and I'll have a look how this PMA_getRelationsParamDiagnostic() works.

--
Marc Delisle | phpMyAdmin

--

Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/