The cache in back_sqlite behaves weird. I get two 
different values in different parts of my program from 
calls to getnode to the same class. This happens after I 
update with class.set(**values). I checked that the 
classes are really the same. The bug doesn't appear in 
back_anydbm.


This only happens in the later CVS versions.

Logged In: YES 
user_id=6405

I need a little more information: which value(s) are different? Which parts of 
the program get the different results? What are you updating in the update() 
call? Is it possible for you to produce a minimal code fragment that 
reproduces the problem? A new unit test case would be ideal... 
 

Logged In: YES 
user_id=18721

I reorganized some of my code and now I can't reproduce it 
anymore. Maybe it got fixed by something in CVS till 
yesterday. I will later try to write a testcase for it.

Logged In: YES 
user_id=18721

I was finally able to write a test case which only fails with 
sqlite (and maybe other SQL backends).


I have attached a wincvs diff which I tested with 
roundup-0.5.6. Current CVS errors in the bdm tests.

Logged In: YES 
user_id=6405

Thanks, have added test and fixed the *dbm errors. 
 

Logged In: YES 
user_id=18721

In sqlite (and other SQL databases) a transaction needs to be 
started with BEGIN, and be finished with COMMIT or 
ROLLBACK. Currently it seems (after a brief source scan) that 
all SQL statements are just send to the database, but in that 
case sqlite creates mini transactions for each change and 
effectively writes all changes immedietly. A solution might be 
to send a BEGIN when the database is ready to receive SQL 
commands and after each COMMIT and ROLLBACK command. 
Then the current assumption, that COMMIT and ROLLBACK 
work on everything since the database is open or the last 
commit/rollback was issued, would be correct.

Logged In: YES 
user_id=6405

See the DB-API spec: 
 
http://www.python.org/topics/database/DatabaseAPI-2.0.html 
 
Auto-commit, if available, must be turned off. I believe (having 
done some simple testing) that it is indeed turned off, and that 
an explicit cursor.commit() is required to commit data to the 
database. 
 

Logged In: YES 
user_id=6405

Ah, the cache wasn't being cleared on a rollback(). This is 
fixed in both HEAD and the maint-0-5 maintenance branch 
(both rdbms_common and back_sqlite need updating).