This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi- I am using the KeyTable identity method on a SQLite database with Lightspeed 3.2 (2011-04-03 build). The problem I am seeing in my application is Entities being written with the same Id value, which as I understand it isn't supposed to happen on the KeyTable method. I can see the problem occur in this code: using (MyUnitOfWork work = MyRepository.CreateUnitOfWork()) { work.Add(new MyColor { Description = "Blue" });
work.Add(new Gender { Description = "Male" });
work.Add(new MyColor { Description = "Red" });
work.Add(new Gender { Description = "Female" });
work.Add(new MyColor
{ Description = "Orange" }); work.SaveChanges(); }
After execution, my MyColor and Gender table have all the right values EXCEPT MyColor row "Blue" and Gender row "Female" have the same Id value of 3. My app.config has these relevant values: identityMethod="KeyTable" identityBlockSize="3"
[Now that I write this, that identityBlockSize of 3 is not the default and coincidentlaly or not matches the Id above. I'll trace down the original author of that later and see why that is]. I'd appreciate any thoughts or help in this. Thank you in advance for your time. Lionel |
|
|
I'm not sure what might be going on there: we've never seen this issue on KeyTable as far as I know, and the nondefault IdentityBlockSize should certainly not be an issue. I would suggest putting a TraceLogger onto the LightSpeedContext to check what SELECT and UPDATE statements are being issued to the KeyTable (and when, compared to the Add statements), and to identify what IDs are being allocated to the other entities (to identify if this is a repeating pattern e.g. 3,4,5,3,?,?). That may clarify exactly what is going on under the surface. I have noticed that SQLite does not have a "select for update" lock so it is possible that an issue like this could arise intermittently if multiple processes are allocating IDs from the same database at the same time. (We throttle allocations within a single process so multithreaded code shouldn't suffer this issue -- only multiprocess.) Could there be multiple processes sharing your SQLite database? |
|
|
To follow through on this, the problem was bad code in our application. I appreciate your time answering, Ivan, and your suggestion helped us trace down where we went wrong. Briefly, we have some temporary tables that we initialize during normal activity. This code is close to the code we use to create a database anew. The creation code includes initializing the KeyTable table. Initializing the KeyTable value back to 1 is what caused our issue. Doh. Thank you again for your time. I appreciate the suggestion. |
|