Re: [SQLObject] transactions; cache sync behavior; sqlite3 relatet?

[Herwig H. <hho...@gm...>]

Thanks for your answer

I messed up the code snippet; forgot the commit.
Please check updated attachment.
>    AFAIU, what is going on there is:
>
> -- the code opens the first connection (without a transaction);
> -- a new table is created via connection 1;
> -- a new row is inserted via connection 1;
> -- the code opens another connection, and BEGINs a transaction ;
> -- the code draws two copies of the row via connection1 and connection2;
> -- the code changes the attribute .foo of the FIRST copy;
> -- the code prints the attribute .foo of the SECOND copy that was drawn via
>    another transaction, and the value is still 'init' because it isn't
>    changed - the code hasn't changed trans_dummy.foo yet.
>   
I intended to illustrate following behavior:

Two instances of the same class with same id; one pulled via a 
connection (with cache=False); one pulled via a transaction createt from 
that same connection;
--> Commits to the transaction _do_ invalidate the instance pulled via 
connection (thanks to cache=False);
--> Changes to the connection instance _don't_ invalidate the 
transaction instance;

This asymmetric behavior seems strange to me, since (as far as i 
understood the code), the transaction object even uses the same cache; 
it's using the same DBConnection instance, after all.

I use SQLObject for a GUI app, so I need long living instances; 
transactionally separated.
Can I evade manually syncing all the transactions. If not, what's the 
best way to invalidate a transaction's cache for a given instance/all 
instances of given class. Are there any docs on this?

regards Herwig Hochleitner