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 <[EMAIL PROTECTED]> wrote: > 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@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
