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

On Fri, Nov 12, 2010 at 10:08 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Nov 11, 2010 at 9:22 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > On Fri, Nov 12, 2010 at 12:32 AM, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >>
> >> On Thu, Nov 11, 2010 at 11:41 AM, Jeremy Orlow <jorlow@chromium.org>
> >> wrote:
> >> > 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.
> >>
> >> Pablo did bring up a good use case, which is wanting to migrate
> >> existing data to a new object store, for example with a new schema.
> >> And every database examined so far has some ability to specify
> >> autonumbered columns.
> >>
> >> overlaps aren't a problem in practice since 64bit integers are really
> >> really big. So unless someone "maliciously" sets a number close to the
> >> upper bound of that then overlaps won't be a problem.
> >
> > Yes, but we'd need to spec this, implement it, and test it because
> someone
> > will try to do this maliciously.
>
> I'd say it's fine to treat the range of IDs as a hardware limitation.
> I.e. similarly to how we don't specify how much data a webpage is
> allowed to put into DOMStrings, at some point every implementation is
> going to run out of memory and effectively limit it. In practice this
> isn't a problem since the limit is high enough.
>
> Another would be to define that the ID is 64 bit and if you run out of
> IDs no more rows can be inserted into the objectStore. At that point
> the page is responsible for creating a new object store and compacting
> down IDs. In practice no page will run into this limitation if they
> use IDs increasing by one. Even if you generate a new ID a million
> times a second, it'll still take you over half a million years to run
> out of 64bit IDs.


This seems reasonable.  OK, let's do it.


> > And, in the email you replied right under, I brought up the point that
> this
> > feature won't help someone who's trying to import data into a table that
> > already has data in it because some of it might clash.  So, just to make
> > sure we're all on the same page, the use case for this is restoring data
> > into an _empty_ object store, right?  (Because I don't think this is a
> good
> > solution for much else.)
>
> That's the main scenario I can think of that would require this yes.
>
> / Jonas
>