On Mar 18, 2010, at 4:25 PM, Stephan Beal wrote:
> On Thu, Mar 18, 2010 at 8:31 PM, D. Richard Hipp <d...@hwaci.com>
> wrote:
> The "22" is a semi-transient rowid on an internal table (semi-
> transient in the sense that it is different on each repository and
> probably changes when you "rebuild"). Allowing rowids in this context
> is bad design, it seems to me. This is something I am working to fix.
>
> In my experience, sqlite rowids are not transient IFF you explicitly
> declre them in the CREATE TABLE code. e.g. here's a snipped i've got
> lying around:
>
> CREATE TABLE c11n_SQLITE_TBL_N -- c11n_nodes
> (
> rowid INTEGER PRIMARY KEY AUTOINCREMENT,
> pid INTEGER REFERENCES c11n_SQLITE_TBL_N(rowid),
> class TEXT,
> name TEXT
> );
That's correct, and Fossil explicitly declares INTEGER PRIMARY KEYs.
But that isn't the issue here. When you "fossil rebuild", fossil does
"DELETE FROM table" for most of its tables, then reconstructs them by
examining original artifacts. The rowids that get created depend on
the order in which the artifacts are processed, which is arbitrary.
In practice, the artifacts are usually scanned in the same order. And
so many times the rowids will be preserved. But there are no
guarantees there, and so it would be unwise to depend on this.
Further background information:
http://www.fossil-scm.org/fossil/doc/tip/www/fileformat.wiki
http://www.fossil-scm.org/fossil/doc/tip/www/theory1.wiki
D. Richard Hipp
d...@hwaci.com
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
