On Sun, 15 May 2016 10:42:37 -0500
mikeegg1 wrote:
> I was once told of an idea (decades ago) of versioning data within a
> table where one column has a real/float value that is the version
> number.
You can have a point-in-time database if:
* each transaction has an id
* DELETE is
2016-05-15 23:46 GMT+07:00 Dominique Devienne :
> On Sunday, May 15, 2016, Mikael wrote:
> >
> > Would there be any facility whereby after each transaction I do on a
> > database or table, I could somehow make a snapshot so that at any future
> > point in time, I could easily do a SELECT to a
This may be completely irrelevant, but what about storing your sqlite db on
a zfs file system (or another with similar capabilities) and creating a new
zfs snapshot whenever you need to?
I don't know how this'll fly in practice if you have a lot of snapshots or
if you need to create many very
2016-05-15 22:23 GMT+07:00 Mikael :
..
> Aha.
>
> Do you see any way that I could implement *one* layer of branches atop of
> this?
>
> Say 1000 or 10^30 of them.
>
>
Ah, make the selects for the timestamp OR the branchid.
2016-05-15 22:14 GMT+07:00 Simon Slavin :
>
> On 15 May 2016, at 4:02pm, Mikael wrote:
>
> > Simon, yes using only INSERT and DELETE in total would be fine with me
> (and
> > perhaps BEGIN and COMMIT if it's OK).
> >
> > What are you thinking about?
> >
> > Did you see a purely SQL-based
2016-05-15 21:56 GMT+07:00 Simon Slavin :
>
> On 15 May 2016, at 3:52pm, Mikael wrote:
>
> > Would there be any facility whereby after each transaction I do on a
> > database or table, I could somehow make a snapshot so that at any future
> > point in time, I could easily do a SELECT to a given
Hi!
Would there be any facility whereby after each transaction I do on a
database or table, I could somehow make a snapshot so that at any future
point in time, I could easily do a SELECT to a given version/snaphot?
Any solution based purely on SQL would be extremely expensive I guess (e.g.
On Sunday, May 15, 2016, Mikael wrote:
>
> Would there be any facility whereby after each transaction I do on a
> database or table, I could somehow make a snapshot so that at any future
> point in time, I could easily do a SELECT to a given version/snaphot?
WAL basically does this already. But
On 15 May 2016, at 4:23pm, Mikael wrote:
> Do you see any way that I could implement *one* layer of branches atop of
> this?
I suspect that branching would be harder to implement. Storing a branch code
in another column of the table isn't going to help much. You'd need to create
some kind
On 15 May 2016, at 4:02pm, Mikael wrote:
> Simon, yes using only INSERT and DELETE in total would be fine with me (and
> perhaps BEGIN and COMMIT if it's OK).
>
> What are you thinking about?
>
> Did you see a purely SQL-based solution that I don't?
BEGIN and COMMIT make no changes to stored
On 15 May 2016, at 3:52pm, Mikael wrote:
> Would there be any facility whereby after each transaction I do on a
> database or table, I could somehow make a snapshot so that at any future
> point in time, I could easily do a SELECT to a given version/snaphot?
Do you need a solution which works
I was once told of an idea (decades ago) of versioning data within a table
where one column has a real/float value that is the version number. The data in
the table can be committed as necessary. If the data needs to be rolled back
the data can be rolled back/deleted to the table based on the
12 matches
Mail list logo
