>-----Urspr?ngliche Nachricht-----
>Von: James K. Lowden [mailto:jklowden at schemamania.org]
>On Tue, 9 Jun 2015 15:13:47 +0000
>Hick Gunter <hick at scigames.at> wrote:
>
>> xConnect is called whenever SQLite decides it needs to do something
>> with the existing virtual table. There must have been a successful
>> xCreate call (in another session, another thread or another process)
>> before. xConnect is not allowed to fail, even if whatever storage
>> implements the persistant data is no longer present. It should just
>> take note of that fact and let the other routines react appropriately.
>
>I don't see how xConnect can not be allowed to fail. The
>documentation says it may return SQLITE_ERROR, and it must allocate the
>sqlite3_vtab structure, which can fail. If a required resource is not
>available, ISTM returning an error is well advised, lest a call to later
>function fail more mysteriously.
>
>That said, the putative CSV file cannot be deleted between xCreate and
>xConnect if the vtable holds a descriptor to the file. In Linux, the file may
>be unlinked, but the inode is preserved while any open descriptor remains. In
>Windows, the user is prevented from deleting an open file.
>
>Of course the file may go away anyway. It might be on a USB drive and the
>user may pull it. In general, the hardware may fail. That's another reason
>xConnect may return an error.
>
>--jkl
Please consider the following sequence:
- Start application
- CREATE VIRUTAL TABLE mycsv USING CSV ('my.csv'); ==> xCreate gets called,
table is entered into sqlite3_master
- Quit application
- delete the my.csv file ==> nobody is going to stop us, the file is not open
The file is gone, there is no backup, the table mycsv is stuck in your db file
forever.
Not quite.
1) touch my.csv and hope that xConnect is satisfied with an empty file; DROP
TABLE...
2) vi my.csv and enter a header line containing just the fieldnames and hope
that xConnect is fooled into thinking it is a real file; DROP TABLE...
3) pragma writeable_schema; delete from sqlite3_master where name='mycsv';
4) have xConnect not fail on a missing file so that xDestroy may be called
successfully; DROP TABLE...
The only case where xConnect may fail is if you cannot even allocate an
sqlite3_vtab structure. In that case your problems are very much more serious
than a missing backing file.
The proper place to implement handling a missing backing storage file is xOpen
(for SELECT) and xUpdate (for INSERT/UPDATE/DELETE). You choose to either
return an error there, or silently provide no rows on SELECT and ignore INSERTs.
___________________________________________
Gunter Hick
Software Engineer
Scientific Games International GmbH
FN 157284 a, HG Wien
Klitschgasse 2-4, A-1130 Vienna, Austria
Tel: +43 1 80100 0
E-Mail: hick at scigames.at
This communication (including any attachments) is intended for the use of the
intended recipient(s) only and may contain information that is confidential,
privileged or legally protected. Any unauthorized use or dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please immediately notify the sender by return e-mail message and
delete all copies of the original communication. Thank you for your cooperation.
