PySQLite and Autoincrement Keys
achrist at easystreet.com
achrist at easystreet.com
Mon May 26 13:26:23 EDT 2003
Gerhard Häring wrote:
>
> achrist at easystreet.com wrote:
> > If I have a table with an autoincrement key in SQLite, and if I
> > delete the row with the largets key, then add a new row, will or
> > might the key value be re-used?
>
> You could have easily checked that for yourself, haven't you?
>
Yes, but I never believe anything one just one person's account.
When I encountered the problem, I quickly rewrote the data access
part of the big app I'm in a hurry on to just flag deleted records,
kind of like dBase used to. By the time I got it re-written, I
wasn't sure if I really needed to do that, so I posted an inquiry.
I was also inquiring to get reaction of others to see if this is
something that would be the basis for a reasonable request for a
fix to the author of SQLite. If his package isn't doing what the
others all do, maybe it would be a good idea.
> I just tested it and it seems ids are being reused.
>
> > Is this good or bad?
>
> This depends. Mostly bad IMO, because you don't get the behaviour of
> SEQUENCEs in other RDBMS that way.
>
> Also SQLite doesn't support any foreign keys, so you'd have to work
> around this limitation by multiple column CHECK CONSTRAINTs. I'm not
> sure if that's really feasible, as I've never done it myself.
>
> Oh well :-(
>
I think it's bad, too. Is there a way for cascading deletes? Even
if there is, it would not be good for my app, because it keeps lots
of data in memory while it runs, and I didn't think about cascading
deletes for all the dictionaries that modules of my program might
have tucked away. The data is logically unreachable when a row
is deleted. Unfortuanately, it gets reachable again when a new
row gets inserted with the same key.
Al
More information about the Python-list
mailing list