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?
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.
On Thu, Jun 26, 2014 at 3:31 PM, Marc Delisle 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.
-- Marc Delisle | phpMyAdmin
On Thu, Jun 26, 2014 at 3:55 PM, Chirayu Chiripal < chirayu.chiripal@gmail.com> wrote:
On Thu, Jun 26, 2014 at 3:31 PM, Marc Delisle 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 saw the Garvin's comment and if someone can elaborate this part:
"Functions defined in those files could apply any Widget (like FCKEdit, HTMLArea or any custom-made PHP/HTML function) around/instead of the default htmlareas."
Does it means that it can be used to change the default textarea currently used in insert/edit page to something else?
-- Marc Delisle | phpMyAdmin
-- Regards, Chirayu Chiripal phpMyAdmin Intern - Google Summer of Code 2014 https://chirayuchiripal.wordpress.com/
Chirayu Chiripal a écrit :
On Thu, Jun 26, 2014 at 3:55 PM, Chirayu Chiripal < chirayu.chiripal@gmail.com> wrote:
On Thu, Jun 26, 2014 at 3:31 PM, Marc Delisle 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 saw the Garvin's comment and if someone can elaborate this part:
"Functions defined in those files could apply any Widget (like FCKEdit, HTMLArea or any custom-made PHP/HTML function) around/instead of the default htmlareas."
Does it means that it can be used to change the default textarea currently used in insert/edit page to something else?
Yes.
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> 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?
-- Marc Delisle | phpMyAdmin-- Regards, Chirayu Chiripal phpMyAdmin Intern - Google Summer of Code 2014 https://chirayuchiripal.wordpress.com/
Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Thu, Jun 26, 2014 at 8:30 PM, Isaac Bennetch 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> 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, forexample;
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?
-- Marc Delisle | phpMyAdmin-- Regards, Chirayu Chiripal phpMyAdmin Intern - Google Summer of Code 2014 https://chirayuchiripal.wordpress.com/
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> 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>>> 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.
On Tue, Jul 1, 2014 at 6:43 PM, Marc Delisle 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> 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>>> 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 plugini.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 canbe
> 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 andstop
> 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 (throughJavaScript
so when the field loses focus, we validate and display anon-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.
-- Marc Delisle | phpMyAdmin
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.
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?
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.
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 fieldhas a
> "prepend" > > input > > > transformation plugin with prepend text as"phpMyAdmin
" then on > > insert > > > page if someone enters into this field "BringingMySQL 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 featurerequest
> is much > > more than that. Look at the comment from Garvin in theRFE.
> > > > In reality, we don't have to code a credit cardvalidation,
> for example; > > we just have to provide the mechanism by which someonecan
> code their > > own credit card validation and apply it to the inputfield.
> > > > > > 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 pluginoption as
> NULL for > > not null column which would automatically fail the insertor
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 checkedbefore
> > 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" whilestoring
> and it is reversed while fetching. Is there any particularreason for
> doing this? Yes, the reason is backward compatibility, but maybe it's time todo a
radical move about this. In pma__column _info, the transformation column contains a stringending
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 torun, that
would do the conversion. If we do a conversion, it would mean that a pmadb would not bebackward
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
On Wed, Jul 2, 2014 at 8:57 PM, Chirayu Chiripal <chirayu.chiripal@gmail.com
wrote:
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 fieldhas a
> "prepend" > > input > > > transformation plugin with prepend text as"phpMyAdmin
" then on > > insert > > > page if someone enters into this field "BringingMySQL 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 featurerequest
> is much > > more than that. Look at the comment from Garvin inthe RFE.
> > > > In reality, we don't have to code a credit cardvalidation,
> for example; > > we just have to provide the mechanism by whichsomeone can
> code their > > own credit card validation and apply it to the inputfield.
> > > > > > 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 givenin
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 nowbut
it can be > > done like by setting value for invalid data in pluginoption as
> NULL for > > not null column which would automatically fail the insertor
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 aboolean
& error > > variable in transformation plugin which would be checkedbefore
> > 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" whilestoring
> and it is reversed while fetching. Is there any particularreason for
> doing this? Yes, the reason is backward compatibility, but maybe it's time todo a
radical move about this. In pma__column _info, the transformation column contains a stringending
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 torun, that
would do the conversion. If we do a conversion, it would mean that a pmadb would not bebackward
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.
Please, review the work I have done so far: https://github.com/D-storm/phpmyadmin/tree/FR-637. 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.
-- Marc Delisle | phpMyAdmin
-- Regards, Chirayu Chiripal phpMyAdmin Intern - Google Summer of Code 2014 https://chirayuchiripal.wordpress.com/
Hello,
On 7/4/14, 4:12 PM, Chirayu Chiripal wrote:
On Wed, Jul 2, 2014 at 8:57 PM, Chirayu Chiripal <chirayu.chiripal@gmail.com mailto:chirayu.chiripal@gmail.com> wrote:
...
We can provide one SQL script to upgrade and I'll have a look how this PMA_getRelationsParamDiagnostic() works.Please, review the work I have done so far: https://github.com/D-storm/phpmyadmin/tree/FR-637. 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.
So far it looks good. I wonder if we might want to rename "Browser transformation" to something to show that it's the output transformation. I'm thinking "Browser output transformation" or "Browser display transformation". Anyone with opinions about this?
I have briefly gone through the code and nothing jumped out as needing correction or improvement. It looks to me like you're still working on the code to detect outdated table structure and the corresponding update documentation, but other than that it looks like things are going well.
Le 2014-07-04 18:04, Isaac Bennetch a écrit :
Hello,
On 7/4/14, 4:12 PM, Chirayu Chiripal wrote:
On Wed, Jul 2, 2014 at 8:57 PM, Chirayu Chiripal <chirayu.chiripal@gmail.com mailto:chirayu.chiripal@gmail.com> wrote:
...
We can provide one SQL script to upgrade and I'll have a look how this PMA_getRelationsParamDiagnostic() works.Please, review the work I have done so far: https://github.com/D-storm/phpmyadmin/tree/FR-637. 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.
So far it looks good. I wonder if we might want to rename "Browser transformation" to something to show that it's the output transformation. I'm thinking "Browser output transformation" or "Browser display transformation". Anyone with opinions about this?
I would prefer "Browser display transformation", but it depends on how we name the other kind of transformation (the one which handles the custom fields handling).
I have briefly gone through the code and nothing jumped out as needing correction or improvement. It looks to me like you're still working on the code to detect outdated table structure and the corresponding update documentation, but other than that it looks like things are going well.
On Sat, Jul 5, 2014 at 4:29 PM, Marc Delisle marc@infomarc.info wrote:
Le 2014-07-04 18:04, Isaac Bennetch a écrit :
Hello,
On 7/4/14, 4:12 PM, Chirayu Chiripal wrote:
On Wed, Jul 2, 2014 at 8:57 PM, Chirayu Chiripal <chirayu.chiripal@gmail.com mailto:chirayu.chiripal@gmail.com> wrote:
...
We can provide one SQL script to upgrade and I'll have a look how this PMA_getRelationsParamDiagnostic() works.Please, review the work I have done so far: https://github.com/D-storm/phpmyadmin/tree/FR-637. 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.
So far it looks good. I wonder if we might want to rename "Browser transformation" to something to show that it's the output transformation. I'm thinking "Browser output transformation" or "Browser display transformation". Anyone with opinions about this?
I would prefer "Browser display transformation", but it depends on how we name the other kind of transformation (the one which handles the custom fields handling).
As of now, the custom field handler is named 'Input transformation'. Any other suggestions for it?
I have briefly gone through the code and nothing jumped out as needing correction or improvement. It looks to me like you're still working on the code to detect outdated table structure and the corresponding update documentation, but other than that it looks like things are going well.
-- Marc Delisle | phpMyAdmin
On 7/4/14, 4:12 PM, Chirayu Chiripal wrote:
Please, review the work I have done so far: https://github.com/D-storm/phpmyadmin/tree/FR-637. 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.
There is a scenario where I can reproduce some warning/error messages using the transformations (pasted below), but I've confirmed that they also exist in master so they're unrelated to your work here. I'm mentioning it here (1) in case anyone else encounters the messages and thinks about reporting them to you and (2) so I can file a proper bug report shortly.
Regards, ~isaac
Warning in ./libraries/dbi/DBIMysqli.class.php#258 mysqli_query() expects parameter 2 to be string, object given
Backtrace
./libraries/dbi/DBIMysqli.class.php#258: mysqli_query( object, object, integer 0, ) ./libraries/DatabaseInterface.class.php#180: PMA_DBI_Mysqli->realQuery( object, object, integer 1, ) ./libraries/DatabaseInterface.class.php#1406: PMA_DatabaseInterface->tryQuery( object, NULL, integer 1, boolean false, ) ./libraries/insert_edit.lib.php#2440: PMA_DatabaseInterface->fetchValue(object) ./tbl_replace.php#421: PMA_verifyWhetherValueCanBeTruncatedAndAppendExtraData( string 'test', string 'transforms', string 'sql', array, ) Warning in ./libraries/dbi/DBIMysqli.class.php#450 mysqli_num_rows() expects parameter 1 to be mysqli_result, null given
Backtrace
./libraries/dbi/DBIMysqli.class.php#450: mysqli_num_rows(NULL) ./libraries/DatabaseInterface.class.php#2135: PMA_DBI_Mysqli->numRows(NULL) ./libraries/DatabaseInterface.class.php#1413: PMA_DatabaseInterface->numRows(NULL) ./libraries/insert_edit.lib.php#2440: PMA_DatabaseInterface->fetchValue(object) ./tbl_replace.php#421: PMA_verifyWhetherValueCanBeTruncatedAndAppendExtraData( string 'test', string 'transforms', string 'sql', array, )
On Sat, Jul 5, 2014 at 3:41 AM, Isaac Bennetch bennetch@gmail.com wrote:
On 7/4/14, 4:12 PM, Chirayu Chiripal wrote:
Please, review the work I have done so far: https://github.com/D-storm/phpmyadmin/tree/FR-637. 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.
There is a scenario where I can reproduce some warning/error messages using the transformations (pasted below), but I've confirmed that they also exist in master so they're unrelated to your work here. I'm mentioning it here (1) in case anyone else encounters the messages and thinks about reporting them to you and (2) so I can file a proper bug report shortly.
Regards, ~isaac
Warning in ./libraries/dbi/DBIMysqli.class.php#258 mysqli_query() expects parameter 2 to be string, object given
Backtrace
./libraries/dbi/DBIMysqli.class.php#258: mysqli_query( object, object, integer 0, ) ./libraries/DatabaseInterface.class.php#180: PMA_DBI_Mysqli->realQuery( object, object, integer 1, ) ./libraries/DatabaseInterface.class.php#1406:
PMA_DatabaseInterface->tryQuery(
object, NULL, integer 1, boolean false, ) ./libraries/insert_edit.lib.php#2440:
PMA_DatabaseInterface->fetchValue(object)
./tbl_replace.php#421:
PMA_verifyWhetherValueCanBeTruncatedAndAppendExtraData(
string 'test', string 'transforms', string 'sql', array, ) Warning in ./libraries/dbi/DBIMysqli.class.php#450 mysqli_num_rows() expects parameter 1 to be mysqli_result, null given
Backtrace
./libraries/dbi/DBIMysqli.class.php#450: mysqli_num_rows(NULL) ./libraries/DatabaseInterface.class.php#2135:
PMA_DBI_Mysqli->numRows(NULL)
./libraries/DatabaseInterface.class.php#1413:
PMA_DatabaseInterface->numRows(NULL)
./libraries/insert_edit.lib.php#2440:
PMA_DatabaseInterface->fetchValue(object)
./tbl_replace.php#421:
PMA_verifyWhetherValueCanBeTruncatedAndAppendExtraData(
string 'test', string 'transforms', string 'sql', array, )
Yes, even I have encountered these error messages but I don't have the exact steps to reproduce them.
On 7/2/14, 9:05 AM, Marc Delisle 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 :
...
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
This is not bad, but -- remember that I haven't actually tried to code what I'm about to describe so I could be wrong -- it seems it wouldn't be much more work from this to actually update the table structure for the user. If in PMA_getRelationsParamDiagnostic() we can detect when the table structure is outdated and display a message, can't we just as easily run the query to update the table? We can't just automatically add a table (because the table has to be added to config.inc.php) or create the entire database (because we don't know the username and password the user wishes to use), but it seems the update could be done without needing to involve the user. Remember, many users don't like to read the documentation, so the more we can do without involving them, the better the user experience will be.
Now, whether people agree with me and whether it actually make sense to do that are two other matters, but hopefully at least my statement makes some sense.
Regards, ~isaac
Le 2014-07-04 17:41, Isaac Bennetch a écrit :
On 7/2/14, 9:05 AM, Marc Delisle 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 :...
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
This is not bad, but -- remember that I haven't actually tried to code what I'm about to describe so I could be wrong -- it seems it wouldn't be much more work from this to actually update the table structure for the user. If in PMA_getRelationsParamDiagnostic() we can detect when the table structure is outdated and display a message, can't we just as easily run the query to update the table? We can't just automatically add a table (because the table has to be added to config.inc.php) or create the entire database (because we don't know the username and password the user wishes to use), but it seems the update could be done without needing to involve the user. Remember, many users don't like to read the documentation, so the more we can do without involving them, the better the user experience will be.
Now, whether people agree with me and whether it actually make sense to do that are two other matters, but hopefully at least my statement makes some sense.
Regards, ~isaac
Indeed it makes sense to update the table structure for the users.
On Sat, Jul 5, 2014 at 4:26 PM, Marc Delisle marc@infomarc.info wrote:
Le 2014-07-04 17:41, Isaac Bennetch a écrit :
On 7/2/14, 9:05 AM, Marc Delisle 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 :...
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
This is not bad, but -- remember that I haven't actually tried to code what I'm about to describe so I could be wrong -- it seems it wouldn't be much more work from this to actually update the table structure for the user. If in PMA_getRelationsParamDiagnostic() we can detect when the table structure is outdated and display a message, can't we just as easily run the query to update the table? We can't just automatically add a table (because the table has to be added to config.inc.php) or create the entire database (because we don't know the username and password the user wishes to use), but it seems the update could be done without needing to involve the user. Remember, many users don't like to read the documentation, so the more we can do without involving them, the better the user experience will be.
Now, whether people agree with me and whether it actually make sense to do that are two other matters, but hopefully at least my statement makes some sense.
Regards, ~isaac
Indeed it makes sense to update the table structure for the users.
Hello, I have added auto detection and upgrade logic for pma__column_info table. What I did is that, I created one upgrade_column_info_4_3_0+.sql file under examples directory for the manual/auto upgrade. In PMA_checkRelationsParam(), if pma__column_info table is present then we check whether it has input transformations columns or not. If they are present then there is no need to upgrade otherwise we try to silently upgrade the table for user by executing the upgrade_column_info_4_3_0+.sql file. The overhead will be of 1 query which is executed once per login for checking columns.
The feature seems complete except few documentation work which will be added soon. Meanwhile, you can review the work here: https://github.com/D-storm/phpmyadmin/tree/FR-637
-- Marc Delisle | phpMyAdmin
-
Chirayu Chiripal -
Isaac Bennetch -
Marc Delisle