On Wed, Jul 2, 2014 at 6:35 PM, Marc Delisle <marc(a)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(a)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(a)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(a)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.