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 there. I'm trying to solve a problem I have when calling a stored proc (returns a result set) via lightspeed.
Singularly it works fine, but in some cases we call this proc multiple times within a transaction, for each item we are processing, within a transaction. After searching the forums I've realised the error of my ways. The Id column returned in my result set is an Identity column of a temporary table. Meaning for each call the Id's will always start at 1, therefore subsequent calls will always grab the entities for the result set from Lightspeed's L1 Cache (Identity Map). The obvious solution is to make the Id column return something more meaningful. In the absence of a suitable "real" Id, what would you recommend as best practice? - solution 1: make my proc's Id column a Guid instead of Identity? - solution 2: ignore the fake Id's altogether and call SaveChanges(true) in between calls. Solution 1 is my preference, but is there anything else I could do to prevent the previous items being retrieved from the Identity Map at all for just this proc/entity on my model? |
|
|
|
|
Not really. Entities live in the identity map and are keyed by ID. If you want to use entities to represent things with duplicate IDs, the only way to get around this is to de-duplicate the IDs, or to clear out the identity map whenever a duplicate could be about to happen! The first option means either changing the sproc to return a unique value (such as a GUID), or mapping a different (and unique) column or set of columns to the ID. If the rows are just one-off records without persistent identity, then the GUID approach is the simplest. If the things you're selecting into the temp table really do have identity, and you want LightSpeed to return the same object if multiple calls to the sproc return the same thing twice, then you'll need to take the second option. The second approach corresponds to calling SaveChanges(true) in between calls, or using a different UOW for each call. The latter approach feels a bit cleaner, but it would use a new database connection for each call, which might not be acceptable for performance or transactional reasons. |
|
|
|
|
Cool. Thanks for the quick reply. |
|
|
|
