[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] (python) how to define unchangeable global ID in a
From:       Simon Slavin <slavins () bigfraud ! org>
Date:       2010-06-28 21:59:18
Message-ID: CF19F8FA-66D8-47B8-8086-60B2DF3BF324 () bigfraud ! org
[Download RAW message or body]


On 28 Jun 2010, at 7:31pm, Pavel Ivanov wrote:

> > Such freedom is not suitable for data interchange between two systems. Not
> > that SQLite or any other database would change the PK during import-export,
> > but they are free to do so as long as the *intramural* integrity is
> > preserved.
> 
> Can you point out some documentation supporting this claim?
> I've no time now to search internet on this matter but I believe DBMS
> changing data that *I stored* in it is fundamentally broken. I
> wouldn't advise anybody to use it. DBMS is allowed to change only
> internal details which do not appear in CREATE TABLE and INSERT
> statements (like ROWID for example).

This /is/ how SQLite behaves.  If you allow it to do its own thing with _rowid_, and \
never refer to it, it feels free to change _rowid_ values any time it likes.  If you \
define a column and it says "Hey, I can save space because I already have _rowid_ \
which fits those requirements." then since it knows you can access the values in that \
column it won't ever change them.  Makes perfect sense to me.

By the way, these cases where SQLite may change _rowid_ values are not mundane.  I \
think the only place I've seen it documented is for VACUUM or for autovacuums.

Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


[prev in list] [next in list] [prev in thread] [next in thread]