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

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.

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

J