> > > > Any DB update or insert or vacuum or analyze might alter the > > > > row order produced where the ordering isn't explicit. > I am interested only in the same ordering between two subsequent > query executions. The things which can happen in between are: > * checkpointing > * close/open in with different journal mode: DELETE->WAL/WAL->DELETE
You can't assume that it'll give you the same ordering even if nothing at all happens in between. You can't assume even that two executions on exactly the same database, under exactly the same conditions, will return in the same order. There's no contractual requirement for the implementation to be deterministic. If you write code and it works today, it might not work tomorrow. Imagine: perhaps the internals of sqlite will be rewritten tomorrow; perhaps the query will be executed on two threads, and the results of the two threads will be merged; perhaps they'll be merged arbitrarily if there's no reason to return the results in a specified order. This won't be a breaking change as far as the sqlite API is concerned; but it'll break your code. The only safe way to write the code is to go by the strict semantics of the statements you're executing; i.e., trust it to fulfil its contract, but nothing else. James ________________________________ Elsevier Limited. Registered Office: The Boulevard, Langford Lane, Kidlington, Oxford, OX5 1GB, United Kingdom, Registration No. 1982084, Registered in England and Wales. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
