> 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.) >
***Sorry, my previous message was a disaster 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 start 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
