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'm using a nightly build of lightspeed with PostgreSQL on Windows (client Windows, Server Linux). Anyway, my problem seems to be more LS related: If I add a new entity AFTER issuing a call to SaveChanges() I get the "Entity has already been added" exception somethwhre beneath: Mindscape.LightSpeed.UnitOfWork.Add(Entity entity) The reason I think this has to do with LS internally is that I can use UnitOfWork.Add() just fine for adding a few thousands of Entities (including from the concrete type that I get the exception for) before I use SaveChanges(). SaveChanges works flawlessly as well, The only apprent issue is that I faild with Add() only AFTER SaveChanges(). I'm using KeyTable as the Identity method for the context. If I turn on Verbose Logging, I can see that there seems to be a problem with the values inserted to the KeyTable table: I have TWO update statements that seem to put the SAME value into NextId... UPDATE If you wish, I can send someone in Mindscape a complete log of the SQL issued...
|
|
|
The nightly build is: LightSpeedExpress-20090430.msi |
|
|
I've managed to "circumvent the bug for now by craeting the context as such: _context = new LightSpeedContext<EGLScanner.Model.UnitOfWork>("PostgreSQL") { This is naturally a very ugly hack to get LS not to reset the KeyTable... Is there anything that can be done with this bug? This looks to be something specific to Postgres...
|
|
|
I've taken a look at this but haven't been able to reproduce it. Would it be possible for you to send us a small project (e.g. a console application plus CREATE TABLE script) that reproduces the problem? Thanks! You can attach a zip file via the Options tab, or email to ivan @ the obvious domain name (please strip out all binaries first). |
|
|
By the way, it looks like current builds of LightSpeed no longer ever emit that exception message (though I still can't reproduce the problem even if I restore that check). Could you try installing the current nightly build and see if that addresses the problem? Thanks! (I'm still concerned about your seeing two identical updates to the KeyTable though.) |
|
|
Hi Ivan, I've moved on to using "Sequnce" as an identity method on postgers as it feels more natural at any rate. You are correct about the error message being replaced of course, and I am now getting a direct error message from Npgsql regarding a pkey contraint that has been violated (both with KeyTable & Sequence). I think I have a discovered the root of the error I'm getting when using Sequences as the identity method. Once I dropped the LightSpeedContext Key allocation block to exactly 100 I stopped getting exceptions... Hope this helps finding that bug. I'll try this with the latest nightly to make sure everything still works with Npgsql 2.0.5 |
|
|
We had a bug in 2.2 RTM which would yield duplicate keys if the IdentityBlockSize was greater than the sequence INCREMENT BY. You've obviously found the recommended workaround, but the bug should be fixed in current nightly builds, so if you go back to your original settings and the error still occurs, please do let us know -- thanks! |
|