25 Jun
2014
25 Jun
'14
7:23 a.m.
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?
--
Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/
26 Jun
26 Jun
7:01 a.m.
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.
--
Marc Delisle | phpMyAdmin
7:25 a.m.
On Thu, Jun 26, 2014 at 3:31 PM, Marc Delisle <marc(a)infomarc.info> wrote:
Le 2014-06-25 06:23, Chirayu Chiripal a écrit :
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.
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.
--
Marc Delisle | phpMyAdmin
--
Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/
7:52 a.m.
On Thu, Jun 26, 2014 at 3:55 PM, Chirayu Chiripal <
chirayu.chiripal(a)gmail.com> wrote:
On Thu, Jun 26, 2014 at 3:31 PM, Marc Delisle
<marc(a)infomarc.info> wrote:
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?
Le 2014-06-25 06:23, Chirayu Chiripal a écrit :
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.
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.
--
Marc Delisle | phpMyAdmin
--
Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/
11:12 a.m.
Chirayu Chiripal a écrit :
On Thu, Jun 26, 2014 at 3:55 PM, Chirayu Chiripal
<
chirayu.chiripal(a)gmail.com> wrote:
Yes.
--
Marc Delisle (phpMyAdmin)
On Thu, Jun 26, 2014 at 3:31 PM, Marc Delisle
<marc(a)infomarc.info> wrote:
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? Le 2014-06-25 06:23, Chirayu Chiripal a écrit :
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.
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.
noon
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>> wrote:
Le 2014-06-25 06:23, Chirayu Chiripal a écrit :
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?
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
--
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
1 Jul
1 Jul
9:43 a.m.
On Thu, Jun 26, 2014 at 8:30 PM, Isaac Bennetch <bennetch(a)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:
example;
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?
On Thu, Jun 26, 2014 at 3:31 PM, Marc Delisle
<marc(a)infomarc.info
<mailto:marc@infomarc.info>> wrote:
Le 2014-06-25 06:23, Chirayu Chiripal a écrit :
and
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"
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 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/
10:13 a.m.
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>> 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:
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.
--
Marc Delisle | phpMyAdmin
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>>> 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
the
web" and
transformation plugin with prepend text as
"phpMyAdmin " then on
insert
> page if someone enters into this field "Bringing MySQL to > when a row is inserted then it should
insert "phpMyAdmin
Bringing
MySQL
is much
to the web" into the database.
OR it requires something else?
Hi Chirayu,
the example you mention is correct, but this feature request 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?
10:26 a.m.
On Tue, Jul 1, 2014 at 6:43 PM, Marc Delisle <marc(a)infomarc.info> wrote:
Le 2014-07-01 08:43, Chirayu Chiripal a écrit :
i.e.
be
stop
JavaScript
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.
On Thu, Jun 26, 2014 at 8:30 PM, Isaac Bennetch <bennetch(a)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:
then on
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>>> 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 "
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
is much
to the web" into the database.
OR it requires something else?
Hi Chirayu,
the example you mention is correct, but this feature request 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 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 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 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 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.
--
Marc Delisle | phpMyAdmin
--
Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/
2 Jul
2 Jul
9:31 a.m.
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 :
plugin
i.e.
in the
make the
Fine with me, but please confirm with your mentor.
--
Marc Delisle | phpMyAdmin
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
" then on
doubt:
>
> 1] Does this feature requests says that if a field has a
"prepend"
> input
> > transformation plugin with prepend text as "phpMyAdmin
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
is much
to the web" into the database.
OR it requires something else?
Hi Chirayu,
the example you mention is correct, but this feature request 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 > 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 > 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 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.
9:50 a.m.
On 7/2/14, 8:31 AM, Marc Delisle wrote:
Le 2014-07-01 09:26, Chirayu Chiripal a écrit :
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?
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 :
plugin
i.e.
in the
make the
Fine with me, but please confirm with your mentor.
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
" then on
doubt:
>
> 1] Does this feature requests says that if a field has a
"prepend"
> input
> > transformation plugin with prepend text as "phpMyAdmin
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 > 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 > 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 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.
10:05 a.m.
Le 2014-07-02 08:50, Isaac Bennetch a écrit :
On 7/2/14, 8:31 AM, Marc Delisle wrote:
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.
--
Marc Delisle | phpMyAdmin
Le 2014-07-01 09:26, Chirayu Chiripal a écrit :
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?
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 :
Fine with me, but please confirm with your mentor.
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.
12:27 p.m.
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 :
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.
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. --
Marc Delisle | phpMyAdmin
--
Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/
4 Jul
4 Jul
5:12 p.m.
On Wed, Jul 2, 2014 at 8:57 PM, Chirayu Chiripal <chirayu.chiripal(a)gmail.com
wrote:
> 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.
>
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/
7:04 p.m.
Hello,
On 7/4/14, 4:12 PM, Chirayu Chiripal wrote:
On Wed, Jul 2, 2014 at 8:57 PM, Chirayu Chiripal
<chirayu.chiripal(a)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.
5 Jul
5 Jul
7:59 a.m.
Le 2014-07-04 18:04, Isaac Bennetch a écrit :
Hello,
On 7/4/14, 4:12 PM, Chirayu Chiripal wrote:
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).
On Wed, Jul 2, 2014 at 8:57 PM, Chirayu Chiripal
<chirayu.chiripal(a)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.
--
Marc Delisle | phpMyAdmin
8:17 a.m.
On Sat, Jul 5, 2014 at 4:29 PM, Marc Delisle <marc(a)infomarc.info> wrote:
--
Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/
Le 2014-07-04 18:04, Isaac Bennetch a écrit :
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?
Hello,
On 7/4/14, 4:12 PM, Chirayu Chiripal wrote:
to
On Wed, Jul 2, 2014 at 8:57 PM, Chirayu Chiripal
<chirayu.chiripal(a)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 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.
--
Marc Delisle | phpMyAdmin
4 Jul
4 Jul
7:11 p.m.
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,
)
5 Jul
5 Jul
3:35 a.m.
On Sat, Jul 5, 2014 at 3:41 AM, Isaac Bennetch <bennetch(a)gmail.com> wrote:
On 7/4/14, 4:12 PM, Chirayu Chiripal wrote:
Yes, even I have encountered these error messages but I don't have the
exact steps to reproduce them.
--
Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/
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,
)
4 Jul
4 Jul
6:41 p.m.
On 7/2/14, 9:05 AM, Marc Delisle wrote:
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-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 :
...
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.
5 Jul
5 Jul
7:56 a.m.
Le 2014-07-04 17:41, Isaac Bennetch a écrit :
On 7/2/14, 9:05 AM, Marc Delisle wrote:
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.
--
Marc Delisle | phpMyAdmin
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 :
...
>
>
> 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?
7 Jul
7 Jul
8:58 a.m.
On Sat, Jul 5, 2014 at 4:26 PM, Marc Delisle <marc(a)infomarc.info> wrote:
Le 2014-07-04 17:41, Isaac Bennetch a écrit :
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
On 7/2/14, 9:05 AM, Marc Delisle wrote:
moving
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 :
...
>>>>
>>>>
>>>> Well, to separate the input & output transformations I would be
>>>> 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 --
Marc Delisle | phpMyAdmin
--
Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/
3715
days inactive
3727
days old
21 comments
3 participants
participants (3)
-
Chirayu Chiripal -
Isaac Bennetch -
Marc Delisle