Re: [sqlite] Huge numbers of savepoints.

[Chris Dew]

That's just what I was looking for.

Thanks,

Chris.

On Aug 23, 4:36 pm, Doug Currie  wrote:
> On Aug 23, 2009, at 6:46 AM, Chris Dew wrote:
>
> > Note: this is not for production code, just an experiment in keeping a
> > history of application 'state', allowing current state to be
> > recalculated if an historic input is received 'late'.  See
> >http://www.finalcog.com/haskell-decoupling-time-from-physicsfor a
> > similar idea (implemented in Haskell).
>
> This page might give you some ideas:
>
> http://www.sqlite.org/cvstrac/wiki?p=UndoRedo
>
> e
>
> ___
> sqlite-users mailing list
> sqlite-us...@sqlite.orghttp://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

Re: [sqlite] Huge numbers of savepoints.

[Doug Currie]

On Aug 23, 2009, at 6:46 AM, Chris Dew wrote:

> Note: this is not for production code, just an experiment in keeping a
> history of application 'state', allowing current state to be
> recalculated if an historic input is received 'late'.  See
> http://www.finalcog.com/haskell-decoupling-time-from-physics for a
> similar idea (implemented in Haskell).

This page might give you some ideas:

http://www.sqlite.org/cvstrac/wiki?p=UndoRedo

e

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Huge numbers of savepoints.

[Pavel Ivanov]

With these requirements you can't implement it just on database level
because it doesn't fit into the standard savepoint/transaction
paradigm of databases. Only committed data and finished transactions
will be available after OS crash or to other processes. After
transaction is committed it cannot be rollbacked - data is saved in
database and DBMS cannot do anything with it until application says
what exactly it should do.
So what you need to do can be implemented only on application level.
You can do some sort of logging of your actions and doing opposite
actions and cleaning the log when you need it.

Pavel

On Sun, Aug 23, 2009 at 6:46 AM, Chris Dew wrote:
> Hi, thanks for your questions.
>
> 1. restarts or OS crashes should leave the data in a sane state - the
> last savepoint would be fine.
> 2. there's no requirement to revert to old savepoints set during a
> previous application run.
> 3. no need for more than one process to access the data, though
> letting other processes see the data at the last save point would be
> nice.
>
> Note: this is not for production code, just an experiment in keeping a
> history of application 'state', allowing current state to be
> recalculated if an historic input is received 'late'.  See
> http://www.finalcog.com/haskell-decoupling-time-from-physics for a
> similar idea (implemented in Haskell).
>
> Regards,
>
> Chris.
>
> On Aug 19, 2:36 pm, Pavel Ivanov  wrote:
>> But how do you expect your application to deal with restarts and/or OS
>> crashes? Do you want to still be able to revert to "marks" set in
>> previous application run or not? And what about accessing to the data
>> stored between "marks" from other processes?
>>
>> Pavel
>>
>>
>>
>> On Wed, Aug 19, 2009 at 4:07 AM, Chris Dew wrote:
>> >http://www.sqlite.org/lang_savepoint.html
>> > I'm looking for a datastore with the following properties:
>> >  * I need to 'mark' the state frequently (sub second interval).
>> >  * I need to be able to revert the datastore to a previous mark (with no
>> > appreciable delay).
>> >  * I only need to keep the last few hundred 'marks'. (i.e. I never need to
>> > revert to a datastore marked more than a few minutes ago.)
>>
>> > The savepoint functionality in sqlite looks to almost fit the bill, but its
>> > savepoints seem to be nested - i.e. you cannot 'forget about' old 
>> > savepoints
>> > while retaining recent savepoints. Is my understanding correct here? I'm
>> > concerned that this would cause a performance issue when millions of nested
>> > savepoints have accumulated.
>>
>> > Obviously I can roll my own data structure here, but is sqlite was 
>> > feasible,
>> > it would be good.
>>
>> > Does anyone have any suggestions?
>>
>> > Thanks,
>>
>> > Chris.
>>
>> > --
>>
>> >http://www.finalcog.com/
>> > ___
>> > sqlite-users mailing list
>> > sqlite-us...@sqlite.org
>> >http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>> ___
>> sqlite-users mailing list
>> sqlite-us...@sqlite.orghttp://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
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Huge numbers of savepoints.

[Chris Dew]

Hi, thanks for your questions.

1. restarts or OS crashes should leave the data in a sane state - the
last savepoint would be fine.
2. there's no requirement to revert to old savepoints set during a
previous application run.
3. no need for more than one process to access the data, though
letting other processes see the data at the last save point would be
nice.

Note: this is not for production code, just an experiment in keeping a
history of application 'state', allowing current state to be
recalculated if an historic input is received 'late'.  See
http://www.finalcog.com/haskell-decoupling-time-from-physics for a
similar idea (implemented in Haskell).

Regards,

Chris.

On Aug 19, 2:36 pm, Pavel Ivanov  wrote:
> But how do you expect your application to deal with restarts and/or OS
> crashes? Do you want to still be able to revert to "marks" set in
> previous application run or not? And what about accessing to the data
> stored between "marks" from other processes?
>
> Pavel
>
>
>
> On Wed, Aug 19, 2009 at 4:07 AM, Chris Dew wrote:
> >http://www.sqlite.org/lang_savepoint.html
> > I'm looking for a datastore with the following properties:
> >  * I need to 'mark' the state frequently (sub second interval).
> >  * I need to be able to revert the datastore to a previous mark (with no
> > appreciable delay).
> >  * I only need to keep the last few hundred 'marks'. (i.e. I never need to
> > revert to a datastore marked more than a few minutes ago.)
>
> > The savepoint functionality in sqlite looks to almost fit the bill, but its
> > savepoints seem to be nested - i.e. you cannot 'forget about' old savepoints
> > while retaining recent savepoints. Is my understanding correct here? I'm
> > concerned that this would cause a performance issue when millions of nested
> > savepoints have accumulated.
>
> > Obviously I can roll my own data structure here, but is sqlite was feasible,
> > it would be good.
>
> > Does anyone have any suggestions?
>
> > Thanks,
>
> > Chris.
>
> > --
>
> >http://www.finalcog.com/
> > ___
> > sqlite-users mailing list
> > sqlite-us...@sqlite.org
> >http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> ___
> sqlite-users mailing list
> sqlite-us...@sqlite.orghttp://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

Re: [sqlite] Huge numbers of savepoints.

[Chris Dew]

Apologies for multiple posting - these extra copies were sent from
googlemail.com, whereas I has subscribed to the list as gmail.com.

Chris.

On Aug 19, 8:35 am, Chris Dew  wrote:
> http://www.sqlite.org/lang_savepoint.html
> I'm looking for a datastore with the following properties:
>  * I need to 'mark' the state frequently (sub second interval).
>  * I need to be able to revert the datastore to a previous mark (with no
> appreciable delay).
>  * I only need to keep the last few hundred 'marks'.  (i.e. I never need to
> revert to a datastore marked more than a few minutes ago.)
>
> The savepoint functionality in sqlite looks to almost fit the bill, but its
> savepoints seem to be nested - i.e. you cannot 'forget about' old savepoints
> while retaining recent savepoints.  Is my understanding correct here?  I'm
> concerned that this would cause a performance issue when millions of nested
> savepoints have accumulated.
>
> Obviously I can roll my own data structure here, but is sqlite was feasible,
> it would be good.
>
> Does anyone have any suggestions?
>
> Thanks,
>
> Chris.
> ___
> sqlite-users mailing list
> sqlite-us...@sqlite.orghttp://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

[sqlite] Huge numbers of savepoints.

[Chris Dew]

http://www.sqlite.org/lang_savepoint.html
I'm looking for a datastore with the following properties:
 * I need to 'mark' the state frequently (sub second interval).
 * I need to be able to revert the datastore to a previous mark (with no
appreciable delay).
 * I only need to keep the last few hundred 'marks'.  (i.e. I never need to
revert to a datastore marked more than a few minutes ago.)

The savepoint functionality in sqlite looks to almost fit the bill, but its
savepoints seem to be nested - i.e. you cannot 'forget about' old savepoints
while retaining recent savepoints.  Is my understanding correct here?  I'm
concerned that this would cause a performance issue when millions of nested
savepoints have accumulated.

Obviously I can roll my own data structure here, but is sqlite was feasible,
it would be good.

Does anyone have any suggestions?

Thanks,

Chris.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Huge numbers of savepoints.

[Pavel Ivanov]

But how do you expect your application to deal with restarts and/or OS
crashes? Do you want to still be able to revert to "marks" set in
previous application run or not? And what about accessing to the data
stored between "marks" from other processes?

Pavel

On Wed, Aug 19, 2009 at 4:07 AM, Chris Dew wrote:
> http://www.sqlite.org/lang_savepoint.html
> I'm looking for a datastore with the following properties:
>  * I need to 'mark' the state frequently (sub second interval).
>  * I need to be able to revert the datastore to a previous mark (with no
> appreciable delay).
>  * I only need to keep the last few hundred 'marks'. (i.e. I never need to
> revert to a datastore marked more than a few minutes ago.)
>
> The savepoint functionality in sqlite looks to almost fit the bill, but its
> savepoints seem to be nested - i.e. you cannot 'forget about' old savepoints
> while retaining recent savepoints. Is my understanding correct here? I'm
> concerned that this would cause a performance issue when millions of nested
> savepoints have accumulated.
>
> Obviously I can roll my own data structure here, but is sqlite was feasible,
> it would be good.
>
> Does anyone have any suggestions?
>
> Thanks,
>
> Chris.
>
> --
>
> http://www.finalcog.com/
> ___
> 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

Re: [sqlite] Huge numbers of savepoints.

[Dan Kennedy]

On Aug 19, 2009, at 3:07 PM, Chris Dew wrote:

> http://www.sqlite.org/lang_savepoint.html
> I'm looking for a datastore with the following properties:
> * I need to 'mark' the state frequently (sub second interval).
> * I need to be able to revert the datastore to a previous mark (with  
> no
> appreciable delay).
> * I only need to keep the last few hundred 'marks'. (i.e. I never  
> need to
> revert to a datastore marked more than a few minutes ago.)
>
> The savepoint functionality in sqlite looks to almost fit the bill,  
> but its
> savepoints seem to be nested - i.e. you cannot 'forget about' old  
> savepoints
> while retaining recent savepoints. Is my understanding correct here?

That's correct. "Savepoint" is just another name for "nested  
transaction".

Dan.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Huge numbers of savepoints.

[Chris Dew]

http://www.sqlite.org/lang_savepoint.html
I'm looking for a datastore with the following properties:
 * I need to 'mark' the state frequently (sub second interval).
 * I need to be able to revert the datastore to a previous mark (with no
appreciable delay).
 * I only need to keep the last few hundred 'marks'. (i.e. I never need to
revert to a datastore marked more than a few minutes ago.)

The savepoint functionality in sqlite looks to almost fit the bill, but its
savepoints seem to be nested - i.e. you cannot 'forget about' old savepoints
while retaining recent savepoints. Is my understanding correct here? I'm
concerned that this would cause a performance issue when millions of nested
savepoints have accumulated.

Obviously I can roll my own data structure here, but is sqlite was feasible,
it would be good.

Does anyone have any suggestions?

Thanks,

Chris.

-- 

http://www.finalcog.com/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users