On Tue, Jul 16, 2019 at 4:44 AM Adrian Ho wrote:
> On 15/7/19 11:25 PM, Nelson, Erik - 2 wrote:
> > Dominique Devienne wrote on Monday, July 15, 2019 2:41 AM
> >> That's when you reach for virtual tables (and their "virtual indices").
> >> I.e. you keep your data in native data-structures
On 15/7/19 11:25 PM, Nelson, Erik - 2 wrote:
> Dominique Devienne wrote on Monday, July 15, 2019 2:41 AM
>
>> That's when you reach for virtual tables (and their "virtual indices").
>> I.e. you keep your data in native data-structures (Boost.MultiIndex in my
>> case),
>> and just provide a SQLite
> On Jul 15, 2019, at 3:57 AM, Richard Hipp wrote:
>
> Yeah there is. SQLite has a high-level query language (SQL) that can
> radically simplify application development.
I guess it depends on your programming style. Most apps whose architecture I’m
aware of* either wrap something like an
On Mon, Jul 15, 2019 at 12:57 PM Richard Hipp wrote:
>
> On 7/15/19, Jens Alfke wrote:
> >
> > If you’re going to keep your data in memory, there’s no good reason to use
> > SQLite at all.
>
> Yeah there is. SQLite has a high-level query language (SQL) that can
> radically simplify application
Dominique Devienne wrote on Monday, July 15, 2019 2:41 AM
>That's when you reach for virtual tables (and their "virtual indices").
>I.e. you keep your data in native data-structures (Boost.MultiIndex in my
>case),
>and just provide a SQLite view of it. Much faster than "pure-in-Memory" with
>
On 7/15/19, Jens Alfke wrote:
>
> If you’re going to keep your data in memory, there’s no good reason to use
> SQLite at all.
Yeah there is. SQLite has a high-level query language (SQL) that can
radically simplify application development.
--
D. Richard Hipp
d...@sqlite.org
On 15/7/62 00:05, ardi wrote:
Hi!
I'm going to use sqlite as means of the file format I/O for
applications. One of the critical points in file I/O is saving the
file in a safe way, so that data loss cannot happen (or at least the
risk of happening is minimized as much as possible).
On Mon, Jul 15, 2019 at 8:24 AM Barry wrote:
> For performance reasons I've had to write custom code where I have changing
> data that I need to keep 'indices' on. I found it very difficult to get it
> right, and very fragile. If I didn't need the performance, I would much
> rather have used an
If you use the SQLite backup api to 'backup' (save) the in-memory database
to the disk database, an atomic transaction is used to write the data to
the destination database. This means that all of SQLites usual guarantees
apply: If the operation completes, the disk database will contain a
On Mon, Jul 15, 2019 at 7:26 AM Jens Alfke wrote:
> > On Jul 14, 2019, at 10:05 AM, ardi wrote:
> > Do you have any recommendation for saving the inmemory db in a safe way?
>
> If you’re going to keep your data in memory, there’s no good reason to use
> SQLite at all. Just define custom model
> On Jul 14, 2019, at 10:05 AM, ardi wrote:
>
> Do you have any recommendation for saving the inmemory db in a safe
> way?
If you’re going to keep your data in memory, there’s no good reason to use
SQLite at all. Just define custom model objects that you can operate on
efficiently, and write
On 14 Jul 2019, at 6:05pm, ardi wrote:
> I have read the backup API page (https://www.sqlite.org/backup.html)
> that shows how to read a sqlite db from disk to memory, and how to
> save it back to disk, but it doesn't talk about the topic of
> performing the save in a safe way.
This is a
Hi!
I'm going to use sqlite as means of the file format I/O for
applications. One of the critical points in file I/O is saving the
file in a safe way, so that data loss cannot happen (or at least the
risk of happening is minimized as much as possible). Traditionally,
some applications save their
13 matches
Mail list logo
