> 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. 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. Can you point me to some sample source code (outside of SQLite itself) that implements sqlite3_vfs_register()? Jeff
