Personally I'd skip the 'auto-saving' feature.  Lots of users are used
to being able to mess around with whatever safe in the knowledge that
when they quit their changes will go away.  More over, unless
cross-session undo is a stated goal it provides little value while
potentially balooning file-size for long-lived files and possibly
revealing embarasing information.  As a solution I suggest you come up
with two slightly different schemas one with change-tracking and one
without.  The disk file will be saved without change-tracking.  When
you load a file, first create a connection to a :memory: database, set
up your schema with change tracking, attach your file and pull the
data from the file into your main database.  When you save, attach the
file again and write the data out to it from main. While it may sound
complex, a healthy dose of good object orientation can really help.

On Mon, Aug 18, 2008 at 6:35 PM, Darren Landrum
> D. Richard Hipp wrote:
>> Have you actually run experiments to see if this is the case, or are
>> you just guessing?  My guess would be the combination of the OS disk
>> cache and SQLite's internal page cache will make actual disk I/O
>> relatively rare, even for an on-disk database.
> Okay, I'm guessing, but it's not unreasonable to want to miminize disk
> i/o in our application, right?
> That being said, I like the idea of going without a save button (we'd
> still probably have a "save as") and saving everything straight to the
> disk file, as that would make it easy for sound designers to "get lost"
> in the application and not have to worry about losing anything they do.
> I'm still concerned about parameters which are designed to be modified
> in real time during performance (in the "sitting down and playing the
> keys" sense), but it's only samplers, which stream a huge amount of data
> from disk as they get played, that might be affected.
> Okay, I'll go with that plan for now, and if it turns out to be an
> issue, then I'll look into pulling databases into memory. Thank you for
> your help.
> -- Darren
> _______________________________________________
> sqlite-users mailing list
sqlite-users mailing list

Reply via email to