I am facing some problems when executing a rollback operation in a unit test.
The unit test consists of the following steps:
The first execution works. But if you try to execute it again, this second execution throws a not unique primary key exception (UltraliteJ Error -193) when executing the second step, so the rollback operation (5th step) does not work propertly on the first execution.
If I executes a checkpoint operation at the end of the test all executions works fine. Is this really necessary?
Is there a way (UltraliteJ api) to always checkpoint after commit and rollback? I try to use setAutocheckpoint method in the ConfigFileAndroid object, but it does not work.
Do I need to set "commit-flush" property to "immediate"? How can I do this?
Thank you, Ericsen
asked 31 Jan '12, 07:32
I was able to reproduce this problem. Thanks Renato.
There is currently a bug with DatabaseManager.release() - it finalizes an object in libultralitej12.so, making the shared library unusable, even after the application is closed and restarted. That is because the process that loaded the shared libray is still active even after the application is closed. I will fix that bug. In the meantime, I recommend not using DatabaseManager.release(), but release()-ing all database connections in the application's onDestroy(). If you see a problem when using this approach, please let us know.
answered 29 Mar '12, 10:41
Just to clarify, let's assume the last id is 1.
After the first run, I would expect there to be a row with id = 2.
Then on the second run I would expect the following:
Are you creating Conn1 and Conn2 on separate threads?
Between runs, did you do a SELECT id FROM table to verify there is in fact no IDs?
Can you post the API you used for step 5?
answered 31 Jan '12, 09:39
I created an Android project with Ericsen's test and when I launch it for the second time the exception occurs. But analyzing the code I checked that the Connection "conn1" wasn't released. After I inserted the conn1.release() the exception did not occur.
But I thought, if the developer forgot to close all connections? My alternative is to put the "DatabaseManager.release();" on the "onDestroy()" method of an activity. I have tested this solution and notice that the file with <db name="">.~db continuous to be on my file folder. If I released all the connections shouldn't my <db name="">.~db file be deleted? With this file the exception still occurs.
If one connection keeps holding the db resources, when I load my application again, the error will occur.
I could not attach my Android Project, don't have enough reputation.
answered 23 Mar '12, 12:20