[Phpmyadmin-devel] Improved notification when attempting to insert invalid data.
bennetch at gmail.com
Fri Aug 1 16:36:07 CEST 2014
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
> at keyup
> > event.
> I prefer a consistent experience for the user. Even though many
> 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
> 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
> 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
> Another thought: we should allow the user to continue even if we
> 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.
> 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.
> Phpmyadmin-devel mailing list
> Phpmyadmin-devel at lists.sourceforge.net
More information about the Developers