There are a lot of people who go on this journey, and I don't recommend it. If you want to take advantage of iCloud, it's best to use Core Data directly, perhaps with an API shim of your own making that makes it easier and more suitable to your needs.
On Apr 25, 2015, at 12:41 PM, Jeff M <jmat at mac.com> wrote: > On Apr 24, 2015, at 2:44 AM, Simon Slavin <slavins at bigfraud.org> wrote: >> On 24 Apr 2015, at 6:59am, Jeff M <jmat at mac.com> wrote: >> >>> I don't need to map SQLite to iCloud -- I only need to map SQLite to Core >>> Data. Core Data then takes care of the iCloud issues. >> >> I imagine you'd do that by writing a VFS which used Core Data for storage. >> Core Data could store your data in any of the formats it has drivers for, >> including plaintext files and SQLite. And Core Data could store your data >> in any medium it has drivers for, including local storage and iCloud. >> >> The result might be slow and inefficient, since you're building a DBMS >> (SQLite) on top of a DBMS (Core Data) on top of a DBMS (SQLite). >> >> If you use Core Data the resulting file wouldn't look like a normal SQLite >> database. Core Data stores objects. It doesn't store the rows and columns >> you refer to with SQL commands. Maybe your objects would be table rows. >> >> Simon. > > Originally, I wanted to map my tables, rows, and columns to similarly-named > Core Data entities and attributes so I could continue to use the SQL > language. I was hoping to hook into the SQL parser to get the benefits of > where.c, but I realize now that's impractical. This is possible, but at each step of the way there are reasons to not do it. You'd need to: Create tooling that generates Core Data models from SQL schemas. This means you should probably give up on the ability to make schema changes at runtime. This code will also need to produce a shim that provides Core Data object access to SQLite when it needs row data. Write a vdbe replacement (this has been done before, but I can't find a link at the moment) and write a replacement that converts parsed queries or vm operations into Core Data requests (which will then be converted back into SQLite). Here you will either have to give up certain queries that aren't supported by the Core Data request language (further limiting functionality), or write sufficient compatibility code (regressing performance). If your goal is to use iCloud as the backend, this means you'll likely have to deal with data conflicts, probably at your shim layer. Constantly-connected database systems don't have to deal with this problem because they are always online, and its likely that the right conflict resolution decisions will vary based on your use case. > Your suggestion of working at the file system level is interesting, but my > objects would be disk blocks. I could use a simple Core Data model: one > entity (representing the entire database file) and create one object per > block (each having a binary attribute containing one block of data). It > would be easy to map each file system read() and write() to the corresponding > objects. Using Core Data as a memory array would earn me the Kludge of The > Year Award. But, I see data corruption in my future. I can't recommend this approach either, due to the conflict resolution issues I mention above. If you're using Core Data as a vfs layer and somehow conflict resolution leaves you with pages from two different forks of the database, it's likely that your database will be irrecoverably corrupted. You'll also lose out on a lot of useful features such as model migration, meaning that you'll have to manually orchestrate your own schema changes. > Can you point me to some sample source code (outside of SQLite itself) that > implements sqlite3_vfs_register()? > > Jeff > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
