On Tue, Jul 29, 2014 at 1:32 AM, Isaac Bennetch bennetch@gmail.com wrote:

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

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.

On Tue, Jul 29, 2014 at 11:02 PM, Isaac Bennetch bennetch@gmail.com wrote:

On 7/29/14, 8:16 AM, Chirayu Chiripal wrote:

...

On Tue, Jul 29, 2014 at 1:32 AM, Isaac Bennetch <bennetch@gmail.com mailto:bennetch@gmail.com> wrote:

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

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.

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.

On 8/1/14, 7:09 AM, Chirayu Chiripal wrote:

On Tue, Jul 29, 2014 at 11:33 PM, Chirayu Chiripal <chirayu.chiripal@gmail.com mailto:chirayu.chiripal@gmail.com> wrote:

On Tue, Jul 29, 2014 at 11:02 PM, Isaac Bennetch <bennetch@gmail.com
<mailto:bennetch@gmail.com>> wrote:



    On 7/29/14, 8:16 AM, Chirayu Chiripal wrote:
    > On Tue, Jul 29, 2014 at 1:32 AM, Isaac Bennetch
    <bennetch@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:
    >     > 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

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.

This looks like a great approach.

    >
    >
    > 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.

Good job testing this. I agree that because of this we can rely on the JavaScript 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel