On Tue, Aug 31, 2010 at 10:51, Richard Hipp <d...@sqlite.org> wrote: > My suggestion is that you make a copy of the os_unix.c source file (call it > chromium_vfs.c or anything else that you like) and apply your edits to that > copy. Since you started with an exact copy of the original os_unix.c > source > file, your copy will all the internal utilities and mechanisms as > os_unix.c. You can use all those internal mechanism as much as you want. > Then compile your customized VFS separately and add it to SQLite at > start-time using sqlite3_vfs_register(). >
I have done a proof-of-concept patch, attached to https://bugs.webkit.org/show_bug.cgi?id=45416 Direct link: https://bugs.webkit.org/attachment.cgi?id=66952&action=prettypatch However, Dumitru Daniliuc (dumi) has noticed that we could still reuse large portions of os_unix.c and only provide our own implementation for opening a file (instead of calling "open" directly, it would call "ChromiumBridge::databaseOpenFile". Similarly for database deletion, etc. Now that we have the code to talk about (see above), could you take another look and see if it would be possible to avoid copy-pasting parts of os_unix.c? I'm just trying to explore all possibilities we have - both copying the code (done now), and re-using more of os_unix.c code. On Wed, Sep 1, 2010 at 21:33, Dan Kennedy <danielk1...@gmail.com> wrote: > How do you know which journal file to open or where to create > a master journal file if the client writes to the database? It is hard for me to answer this question (I'm not very familiar with sqlite yet). See the patch above - I think it preserves the semantics of current code used in Chrome, just moves it to WebKit. Any feedback on whether that code is right or wrong and how it can be improved would be appreciated. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
