> Paul wrote: > >> pragma user_version; > >> > >> returns a single row with a
> single value which is the version, and the command, > >> > >> pragma
> user_version=n; > >> > >> lets you change it to n. Perhaps you can use this
> as a flag to tell yourself > >> that you are working with an uninitialized
> database (value is 0), that another > >> process is updating the database
> schema (change it to -1), or that it is at > >> some internal revision number
> known to your program (it has a value > 0) such > >> that you do not need to
> change the schema or initialize it. > > > > This is actually very helpful! >
> > This soultion avoids unnecessary transaction after database open. > > I can
> use *double checked locking* and start transaction only if necessary. > >
> Please note that *all* accesses to the database file are done with >
> transactions, including reading and writing the user_version value. > This
> PRAGMA makes it slightly easier to check the database, but you > cannot avoid
> transaction this way
(or with any other way). > > (If the process correctly updates the database
within a transaction, > that value -1 would never be seen by another process.)
Of course, that is why I mentioned *double checked locking*. I can check
whether user_version matches magic number without transaction. Only when
user_version does not match magic number I creat transaction. Then I check
again, inside exclusive transaction, then perform database schema
initialization, if user_version is still not a magic number. Finally assing
user_version that magic number and commit transaction. The only thing I am
worried about is whether pragma user_version=n; respects transactions and will
be rolled back automatically in case if something happens between that
statement and COMMIT.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
