On 10/31/06, Bryan Oakley <[EMAIL PROTECTED]> wrote:
Given that, is there a reliable, portable way to copy a memory db to disk, when that db makes use of the FTS1 module?
I've been pondering this, and nothing good came of it :-). My best suggestion would be to modify your copy system to first create the virtual tables, then create all other tables using "if not exists", then copy all the data for the non-virtual tables. The idea would be to copy the backing of the virtual tables, only using the virtual table interface to handle creation. This might fail if at some point a virtual table uses some sort of backwards compatibility, where the aux table names in an existing database may not match those which would be created for a new table. My second-best suggestion would be to first copy the virtual tables in the standard way _through_ the virtual table interface, then skip any non-virtual tables which already exist in the copy. Two downsides come to mind. This might not get you a dataset which precisely matches the original (in the case of fts1, deletions stored in the doclists would fall away - sort of like a VACUUM operation, which might be good!). Also, it might make things slower. I don't think the default tokenizer for fts1 would be particularily slower for datasets which fit in memory in the first place, but in the general case it's certainly possible. Sounds like you want something like table-renaming, maybe "ALTER TABLE <name> COPY TO <database>;". Hmm. But you'd still have to figure out which ones to copy! -scott ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
