[Phpmyadmin-devel] Improved notification when attempting to insert invalid data.

[Isaac Bennetch]

On 8/1/14, 7:09 AM, Chirayu Chiripal wrote:
> On Tue, Jul 29, 2014 at 11:33 PM, Chirayu Chiripal
> <chirayu.chiripal at gmail.com <mailto:chirayu.chiripal at gmail.com>> wrote:
> 
>     On Tue, Jul 29, 2014 at 11:02 PM, Isaac Bennetch <bennetch at gmail.com
>     <mailto:bennetch at 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 at gmail.com <mailto:bennetch at gmail.com>
>         > <mailto:bennetch at gmail.com <mailto:bennetch at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
>