W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: [Bug 11270] New: Interaction between in-line keys and key generators

From: Jeremy Orlow <jorlow@chromium.org>
Date: Thu, 11 Nov 2010 22:41:00 +0300
Message-ID: <AANLkTinKHSGPtR7Ts8NegtDJOHY7xPgkMScZKdEpsHU2@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Pablo Castro <Pablo.Castro@microsoft.com>, "bugzilla@jessica.w3.org" <bugzilla@jessica.w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>
On Thu, Nov 11, 2010 at 6:41 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Thu, Nov 11, 2010 at 4:20 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > What would we do if what they provided was not an integer?
> The behavior isn't very important; throwing would be fine here.  In
> mySQL, you can only put AUTO_INCREMENT on columns in the integer
> family.
> > What happens if
> > the number they insert is so big that the next one causes overflow?
> The same thing that happens if you do ++ on a variable holding a
> number that's too large.  Or, more directly, the same thing that
> happens if you somehow fill up a table to the integer limit (probably
> deleting rows along the way to free up space), and then try to add a
> new row.
> > What is
> > the use case for this?  Do we really think that most of the time users do
> > this it'll be intentional and not just a mistake?
> A big one is importing some data into a live table.  Many smaller ones
> are related to implicit data constraints that exist in the application
> but aren't directly expressed in the table.  I've had several times
> when I could normally just rely on auto-numbering for something, but
> occasionally, due to other data I was inserting elsewhere, had to
> specify a particular id.

This assumes that your autonumbers aren't going to overlap and is going to
behave really badly when they do.

Honestly, I don't care too much about this, but I'm skeptical we're doing
the right thing here.

Received on Thursday, 11 November 2010 19:41:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC