On Mon, Aug 18, 2008 at 04:38:03PM -0400, Darren Landrum wrote:
> Software synthesis applications, particularly disk-streaming
> samplers, are very high-performance programs, so I'd like to keep
> disk I/O as clear as possible. Every touch of a GUI widget will
> result in a query run on the
Jeffrey Becker wrote:
> All you need to do is pass the string ":memory:" to sqlite3_openxxx
> and it will open a memory-backed database. That said I think your
> first order of business should be to try and define a good abstraction
> around the whole thing. While my C++ is a little rusty heres
All you need to do is pass the string ":memory:" to sqlite3_openxxx
and it will open a memory-backed database. That said I think your
first order of business should be to try and define a good abstraction
around the whole thing. While my C++ is a little rusty heres some C#
pseudo code to get you
Jeffrey Becker wrote:
> 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
Darren Landrum wrote:
> D. Richard Hipp wrote:
>
>> Why do you want to load the database into memory? Why not just open
>> it and use it off of disk?
>>
>
> Software synthesis applications, particularly disk-streaming samplers,
> are very high-performance programs, so I'd like to keep
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
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
On Aug 18, 2008, at 4:38 PM, Darren Landrum wrote:
> Every touch of a GUI widget will result in a query
> run on the database, so it's best that that be in memory, I think.
Have you actually run experiments to see if this is the case, or are
you just guessing? My guess would be the
D. Richard Hipp wrote:
> Why do you want to load the database into memory? Why not just open
> it and use it off of disk?
Software synthesis applications, particularly disk-streaming samplers,
are very high-performance programs, so I'd like to keep disk I/O as
clear as possible. Every touch
Although most of the online documentation for SQLite is OK, I had to
go all the way and buy "The Definitive Guide to SQLite" by Michael
Owens to answer most of my "nuts and bolts" inquiries on the matter.
Most of what you describe seems to be doable without too much hassle.
On Mon, Aug 18, 2008
On Aug 18, 2008, at 2:17 PM, Darren Landrum wrote:
> An object of the class Preset will have the functions to load a
> database into memory
Why do you want to load the database into memory? Why not just open
it and use it off of disk?
D. Richard Hipp
[EMAIL PROTECTED]
I realize that there is a lot written on this subject, and that it's a
popular way of using SQLite, but I'm having trouble finding any
documentation or tutorials that really explain the nuts and bolts. It
doesn't help that I'm still fairly new to C++ programming.
What I want to do is create a
12 matches
Mail list logo
