On 5 Jun 2013, at 8:38pm, Philip Bennefall <phi...@blastbay.com> wrote:
> On 5 Jun 2013, at 8:32pm, Petite Abeille <petite.abei...@gmail.com> wrote: > >> write to tmpfs… read the file into byte[]… do what you meant to do… to >> reload… write byte[] do tmpfs… open db… and be merry… or something along >> these lines... > > I don't want it in a file, however. I want it in a memory block. That's why you read from tmpfs (or any other file stored in any other file system) into byte[]. Once your data is in byte[] you will have entire SQLite database in one run of memory. You can't usefully store a memory database of SQLite because SQLite's data in memory isn't all in one big run of memory. The data is stored in various little chunks, some here, some there. If you tried to read the data directly out of those chunks you would have to read lots of little chunks, not one big run of continuous memory. And you'd be storing lots of pointers to various locations in memory. When you 'restore' the data back into memory you're not going to be allocated the same locations in memory so those pointers won't mean anything any more. A database stored in a file, however, has pointers to locations in that file instead of pointers to locations in memory. If you save and restore the whole file in one big run, those pointers will become valid again: the same bits of data will be at the same offsets of the file. Doesn't have to be tmpfs. You can use any file system that SQLite thinks is file storage rather than memory storage. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
