28 Jul
2014
28 Jul
'14
2:30 p.m.
Hi,
My GSoC task for this week is "Improved notification when attempting to
insert invalid data". I would like to know at which places validation is
required to be done?
--
Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/
28 Jul
28 Jul
5:02 p.m.
New subject: [Phpmyadmin-devel] Improved notification when attempting to insert invalid data.
Hi,
On 7/28/14, 1:30 PM, Chirayu Chiripal wrote:
Hi,
My GSoC task for this week is "Improved notification when attempting to
insert invalid data". I would like to know at which places validation is
required to be done?
The idea here is basically that if a user attempts to insert data that
will be truncated that we'll warn them. Some of this has already been
implemented (for instance, try to insert the text "foo" to a column of
type INT(10); the field turns red indicating a problem).
This can be enhanced, though, for instance the following scenarios do
not warn correctly:
* Insert 999 to a TINYINT
* Insert 99999999999 to an INT
* Insert AES_ENCRYPT to a VARCHAR(5) [note that AES_ENCRYPT should be
associated with a BINARY or VARBINARY column type]
* Insert MD5() data to a VARCHAR(5) (which is too short to hold the hash)
I imagine there are more but those are the ones that have stood out to
me through use.
--
Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.c…
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
29 Jul
29 Jul
9:16 a.m.
New subject: [Phpmyadmin-devel] Improved notification when attempting to insert invalid data.
On Tue, Jul 29, 2014 at 1:32 AM, Isaac Bennetch <bennetch(a)gmail.com> wrote:
Hi,
On 7/28/14, 1:30 PM, Chirayu Chiripal wrote:
For integer types we can change our current input type="text" to input
type="number" and specify a min and max value using attributes. Or, we
still have to add a min and max value attribute and use Javascript/Jquery
to validate the field when it loses focus or at keyup event.
Hi,
My GSoC task for this week is "Improved notification when attempting to
insert invalid data". I would like to know at which places validation is
required to be done?
The idea here is basically that if a user attempts to insert data that
will be truncated that we'll warn them. Some of this has already been
implemented (for instance, try to insert the text "foo" to a column of
type INT(10); the field turns red indicating a problem).
This can be enhanced, though, for instance the following scenarios do
not warn correctly:
* Insert 999 to a TINYINT
* Insert 99999999999 to an INT
2:32 p.m.
New subject: [Phpmyadmin-devel] Improved notification when attempting to insert invalid data.
On 7/29/14, 8:16 AM, Chirayu Chiripal wrote:
On Tue, Jul 29, 2014 at 1:32 AM, Isaac Bennetch
<bennetch(a)gmail.com
<mailto:bennetch@gmail.com>> wrote:
Hi,
On 7/28/14, 1:30 PM, Chirayu Chiripal wrote:
I prefer a consistent experience for the user. Even though many browsers
would properly deal with input type="number", it will give different
feedback than our custom handling of, say, too many characters in a
varchar field. So I would like to be consistent and use our own tests
even for INT columns.
Note that in multibyte character sets, a single character may take
several bytes of data to store. I'm not sure whether it's easy to
correctly count bytes/characters in this case.
Another thought: we should allow the user to continue even if we don't
think the data they're entering is okay -- the input field should turn
red, but they should still be allowed to press the submit button and
allow MySQL to truncate.
Hi,
My GSoC task for this week is "Improved notification when
attempting to
insert invalid data". I would like to know
at which places
validation is
required to be done?
The idea here is basically that if a user attempts to insert data that
will be truncated that we'll warn them. Some of this has already been
implemented (for instance, try to insert the text "foo" to a column of
type INT(10); the field turns red indicating a problem).
This can be enhanced, though, for instance the following scenarios do
not warn correctly:
* Insert 999 to a TINYINT
* Insert 99999999999 to an INT
For integer types we can change our current input type="text" to input
type="number" and specify a min and max value using attributes. Or, we
still have to add a min and max value attribute and use
Javascript/Jquery to validate the field when it loses focus or at keyup
event.
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.c…
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
3:03 p.m.
New subject: [Phpmyadmin-devel] Improved notification when attempting to insert invalid data.
On Tue, Jul 29, 2014 at 11:02 PM, Isaac Bennetch <bennetch(a)gmail.com> wrote:
On 7/29/14, 8:16 AM, Chirayu Chiripal wrote:
Okay, so we will use our own validation.
On Tue, Jul 29, 2014 at 1:32 AM, Isaac Bennetch
<bennetch(a)gmail.com
<mailto:bennetch@gmail.com>> wrote:
Hi,
On 7/28/14, 1:30 PM, Chirayu Chiripal wrote:
that
Hi,
My GSoC task for this week is "Improved notification when
attempting to
insert invalid data". I would like to know
at which places
validation is
required to be done?
The idea here is basically that if a user attempts to insert data will be truncated that we'll warn them.
Some of this has already been
implemented (for instance, try to insert the text "foo" to a column
of
type INT(10); the field turns red indicating
a problem).
This can be enhanced, though, for instance the following scenarios do
not warn correctly:
* Insert 999 to a TINYINT
* Insert 99999999999 to an INT
For integer types we can change our current input type="text" to input
type="number" and specify a min and max value using attributes. Or, we
still have to add a min and max value attribute and use
Javascript/Jquery to validate the field when it loses focus or at keyup
event.
I prefer a consistent experience for the user. Even though many browsers
would properly deal with input type="number", it will give different
feedback than our custom handling of, say, too many characters in a
varchar field. So I would like to be consistent and use our own tests
even for INT columns.
Note that in multibyte character sets, a single character may take
several bytes of data to store. I'm not sure whether it's easy to
correctly count bytes/characters in this case.
Yeah, this is an important thing to be taken care of. I am not sure whether
Javascript supports it natively but there should some way to do it. MySQL
documentation says that "MySQL interprets length specifications in
character column definitions in character units." I am not sure that by
character units they mean unicode "code points" or something else.
Another thought: we should allow the user to continue
even if we don't
think the data they're entering is okay -- the input field should turn
red, but they should still be allowed to press the submit button and
allow MySQL to truncate.
Sure.
1 Aug
1 Aug
8:09 a.m.
New subject: [Phpmyadmin-devel] Improved notification when attempting to insert invalid data.
On Tue, Jul 29, 2014 at 11:33 PM, Chirayu Chiripal <
chirayu.chiripal(a)gmail.com> wrote:
Okay, so we will use our own validation.
To test whether JS handles multibyte character strings length correctly, I
compared the result of MySQL's CHAR_LENGTH(str) and JS's str.length with
some random strings from different languages (Hindi, Gujarati, Chinese,
Japanese) and the results were identical. So, I think we can rely on JS
length property.
On Tue, Jul 29, 2014 at 11:02 PM, Isaac Bennetch
<bennetch(a)gmail.com>
wrote:
One thing which I didn't knew
was that JS can handle numbers upto 53 bits
without loosing precision. But as soon as number goes beyond that, then
some round off error tends to occur. As MySQL, can have integers upto 64
bits length, the JS number comparison will not work. So, I have written my
own BigInts comparison function to compare them in string format itself.
On 7/29/14, 8:16 AM, Chirayu Chiripal wrote:
On Tue, Jul 29, 2014 at 1:32 AM, Isaac Bennetch
<bennetch(a)gmail.com
<mailto:bennetch@gmail.com>> wrote:
Hi,
On 7/28/14, 1:30 PM, Chirayu Chiripal wrote:
that
Hi,
My GSoC task for this week is "Improved notification when
attempting to
insert invalid data". I would like to know
at which places
validation is
required to be done?
The idea here is basically that if a user attempts to insert data will be truncated that we'll warn them.
Some of this has already
been
implemented (for instance, try to insert the
text "foo" to a column
of
type INT(10); the field turns red indicating
a problem).
This can be enhanced, though, for instance the following scenarios
do
not warn correctly:
* Insert 999 to a TINYINT
* Insert 99999999999 to an INT
For integer types we can change our current input type="text" to input
type="number" and specify a min and max value using attributes. Or, we
still have to add a min and max value attribute and use
Javascript/Jquery to validate the field when it loses focus or at keyup
event.
I prefer a consistent experience for the user. Even though many browsers
would properly deal with input type="number", it will give different
feedback than our custom handling of, say, too many characters in a
varchar field. So I would like to be consistent and use our own tests
even for INT columns.
Note that in multibyte character sets, a single character may take
several bytes of data to store. I'm not sure whether it's easy to
correctly count bytes/characters in this case.
Yeah, this is an important thing to be taken care of. I am not sure
whether Javascript supports it natively but there should some way to do it.
MySQL documentation says that "MySQL interprets length specifications in
character column definitions in character units." I am not sure that by
character units they mean unicode "code points" or something else.
Another thought: we should allow the user to
continue even if we don't
think the data they're entering is okay -- the input field should turn
red, but they should still be allowed to press the submit button and
allow MySQL to truncate.
Sure.
11:36 a.m.
New subject: [Phpmyadmin-devel] Improved notification when attempting to insert invalid data.
On 8/1/14, 7:09 AM, Chirayu Chiripal wrote:
Good job testing this. I agree that because of this we can rely on the
JavaScript length property.
On Tue, Jul 29, 2014 at 11:33 PM, Chirayu Chiripal
<chirayu.chiripal(a)gmail.com <mailto:chirayu.chiripal@gmail.com>> wrote:
On Tue, Jul 29, 2014 at 11:02 PM, Isaac Bennetch <bennetch(a)gmail.com
<mailto:bennetch@gmail.com>> wrote:
On 7/29/14, 8:16 AM, Chirayu Chiripal wrote:
This looks like a great approach.
On Tue, Jul 29, 2014 at 1:32 AM, Isaac Bennetch
<bennetch(a)gmail.com <mailto:bennetch@gmail.com>
<mailto:bennetch@gmail.com
<mailto:bennetch@gmail.com>>> wrote:
Hi,
On 7/28/14, 1:30 PM, Chirayu Chiripal wrote:
insert data
that
Hi,
My GSoC task for this week is "Improved notification when
attempting to
insert invalid data". I would like to know
at which places
validation is
required to be done?
The idea here is basically that if a user attempts to will be truncated that we'll warn them.
Some of this has
already been
implemented (for instance, try to insert the
text "foo" to
a column of
type INT(10); the field turns red indicating
a problem).
This can be enhanced, though, for instance the following
scenarios do
not warn correctly:
* Insert 999 to a TINYINT
* Insert 99999999999 to an INT
One thing which I didn't knew was that JS can handle numbers upto 53
bits without loosing precision. But as soon as number goes beyond that,
then some round off error tends to occur. As MySQL, can have integers
upto 64 bits length, the JS number comparison will not work. So, I have
written my own BigInts comparison function to compare them in string
format itself.
For integer types we can change our current input type="text"
to
input
type="number" and specify a min and max
value using
attributes. Or, we
still have to add a min and max value attribute
and use
Javascript/Jquery to validate the field when it loses focus or
at keyup
event.
I prefer a consistent experience for the user. Even though many
browsers
would properly deal with input type="number", it will give different
feedback than our custom handling of, say, too many characters in a
varchar field. So I would like to be consistent and use our own
tests
even for INT columns.
Okay, so we will use our own validation.
Note that in multibyte character sets, a single character may take
several bytes of data to store. I'm not sure whether it's easy to
correctly count bytes/characters in this case.
Yeah, this is an important thing to be taken care of. I am not sure
whether Javascript supports it natively but there should some way to
do it. MySQL documentation says that "MySQL interprets length
specifications in character column definitions in character units."
I am not sure that by character units they mean unicode "code
points" or something else.
To test whether JS handles multibyte character strings length correctly,
I compared the result of MySQL's CHAR_LENGTH(str) and JS's str.length
with some random strings from different languages (Hindi, Gujarati,
Chinese, Japanese) and the results were identical. So, I think we can
rely on JS length property.
Another thought: we should allow the user to continue even if we
don't
think the data they're entering is okay -- the input field
should turn
red, but they should still be allowed to press the submit button and
allow MySQL to truncate.
Sure.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
3690
days inactive
3694
days old
6 comments
2 participants
participants (2)
-
Chirayu Chiripal -
Isaac Bennetch