-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > A far better solution ... would be to bump > the VFS version number to 3
That is the only solution that will not break any existing code from anyone. ie you have to use VFS 3 to opt in to getting SYNC_OMITTED (probably best delivered to xSync but xFileControl works too). I strongly believe this is the way you should go - new behaviour bumps version numbers while keeping compatibility for existing code. Perhaps a little tricky if you want to do this in the next few days though ... > Suppose we rig the default VFSes so that they return SQLITE_OK for > SQLITE_FCNTL_SYNC_OMITTED, instead of SQLITE_ERROR, so that your > intermediate layer doesn't throw an exception? That would keep the vast majority of existing deployed code happy. > Another solution we talked about was having the xFileControl method in the > VFS object return SQLITE_NOTFOUND instead of SQLITE_ERROR if it gets an > unknown opcode. That too would solve your problem, wouldn't it? Would it > break anything else? That wouldn't help deployed code since everything other than SQLITE_OK turns into exceptions. For my next release I will make it adapt to whatever you decide. A problem with file control is that you can't tell the difference between the following: 1 - A bad database name 2 - op not understood 3 - op understood and had an error being executed Having NOTFOUND is a solution going forward as I can then distinguish between the last two cases. The third needs to be turned into an Exception while NOTFOUND can be appropriately handled. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1AeRUACgkQmOOfHg372QRThgCfX1pPMMzNRdjvcxapNGKhtCdx yTYAn3P0NaZPQz+mHXAZXNQGVn5Gamhv =UBJn -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
