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 guys, I seem to recall seeing a post from Ivan a while back that mentioned the possibility of supporting reference data scenarios - I can't seem to find any mention in the docs about how best to cope with entities that represent static application values. My biggest issue is that these entities attempt to participate in the usual Lightspeed association handling. Attached is a repro that shows how my Reference Data entities (Status in my example) are causing unnecessary database hits and even exceptions when no UnitOfWork is available. My simple example doesn't show it well, but sometimes it's useful to be able to assign associated (reference data) entities outside the context of a UnitOfWork. Have you got any ideas on how this scenario could better be supported by Lightspeed? Would it be possible to annotate those associations with reference data entities and which are effectively one-way (ie: the reference data entity would not attempt to resolve the backreference). Thanks |
|
|
Hi Greg, Make sure you call uow.Detach(customer2) in the second unitOfWork using scope, by not doing this the customer2 object still think it is attached to a UOW and will attempt to load the Customers collection on the Status object to wire up the reverse association.
Jeremy |
|
|
Hi Jeremy, Thanks for the suggestion. Unfortunately, this doesn't seem to make any difference - I still receive an ObjectDisposed exception when assigning the status to customer2 - whether customer2 has been detached from its UOW or not. Here's the stack trace... at Mindscape.LightSpeed.UnitOfWorkBase.() I also tried detaching the Status entities from the UOW after loading them, but again the exception is raised. Thanks, |
|
|
Hello Greg, The post you're thinking of may be from this thread: http://www.mindscape.co.nz/forums/Thread.aspx?ThreadID=2956 specifically http://www.mindscape.co.nz/forums/Post.aspx?ThreadID=2956&PostID=9595 This uses L2 caching plus an attribute that allows you to get rid of the unwanted to-many direction of the association. I don't know if this will resolve your issue with assignments outside a unit of work though. |
|
|
Hi Ivan, Yes - that post definately sounds like what I'm after. I just tried the suggestion, but alas I get a NullReferenceException when querying for a customer (inside a UOW). Is this feature still a work in progress? Thanks, |
|
|
PS. I'm using the RTM 3.11 version |
|
|
Thanks for reporting this and for the very comprehensive repro. This is a bug in the combination of NoReverseAssociation and EagerLoad. If you remove the EagerLoadAttribute from Customer._status then you'll be golden. "But wait! Won't that hose my performance?" It shouldn't do. Since the Status entities are cached (and in fact you explicitly force them into cache), you won't be incurring a database hit to lazily traverse the Customer.Status association; you'll only be incurring a L2 cache lookup. And you'd probably have incurred that anyway with an eager load. In fact, removing EagerLoad should marginally improve performance* because it saves LightSpeed from composing the eager-load SELECT on the Status table, and the database from executing it. So although this is a bug, we probably won't fix it (except maybe detecting the condition and emitting a meaningful message instead of a NullReferenceException). * No warranties express or implied. Any improvement will probably be imperceptible at best! |
|
|
Hi Ivan, This all sounds great and makes perfect sense..... but..... I'm still receiving the NullReferenceException when querying for a Customer AFTER removing the [EagerLoad] from Customer._status. Here's the stack trace: at Mindscape.LightSpeed.Model.FieldModel..ctor(FieldInfo , TypeModel ) Any ideas? Also, can you put "adding designer support for NoReverseAssociation" onto the product backlog... Cheers, |
|
|
Hi Ivan, Can you confirm if removing [EagerLoad] worked for you? I'm still having difficulty with a NullReferenceException when removing [EagerLoad]... Thanks, |
|
|
Sorry for not replying to your first post -- our email notifications seem to be messed up. Yes, I can confirm that removing [EagerLoad] works for me. I just unzipped your ReferenceDataRepro2 sample into a clean directory, rebuilt the database and added references to the LightSpeed DLLs. When I ran the sample, I got a LightSpeedException. When I commented out the [EagerLoad] at Customer.cs line 14, and re-ran the sample, no exceptions. |
|
|
Hmm, this may be an obfuscation issue -- I'm doing my testing with the unobfuscated DLLs. Let me have a bit more of an investigate. |
|
|
Okay, this was indeed an obfuscation issue. I have committed a fix which will be included in the 7 Sept nightly build. The updated build will also display a meaningful error (instead of a NullReferenceException) if you use EagerLoad and NoReverseAssociation on the same association. And I've strengthened the obfuscation test suite to reduce the chances of a similar issue in future. Apologies for the inconvenience, and please let us know you still see problems (I have re-tested your repro against the MSI though so hopefully this will finally knock it on the head!). |
|
|
Great - thanks Ivan - I'll give it a try tomorrow. |
|
|
Designer support for NoReverseAssociationAttribute will be in the 8 Sept 2010 nightly (available from about 1500 GMT). There's no special setting: just set the association's Collection Name to an empty string. When we see this we will (a) not emit an EntityCollection at the to-many end and (b) emit NRAA on the EntityHolder at the to-one end. As always, please let us know if you discover any problems. |
|
|
Fantastic! Thanks Ivan.
A quick reminder to anyone else following this thread - don't forget to enable the 2nd Level Cache on the Lightspeed Context if you are using the [Cached] attribute on your reference entities. Just setting [Cached] is not enough, you must also initialise the CacheBroker like so: lsContext.Cache = new CacheBroker(new DefaultCache()); |
|
|
Hi Ivan, I was just trying out the above designer changes and noticed the following issue in the generated code for the Customer entity (I'm not sure yet whether this causes an actual problem or is just "undesirable"). [NoReverseAssociation] Cheers, |
|
|
Hmm, I think the NoReverseAssociation attribute will take precedence which makes this merely *ahem* 'undesirable.' Regardless, it will be fixed in the 11 Sept nightly. |
|
|
One more little issue: Consider the situation where a reference data entity is referenced by multiple concrete entity types (for example: InternalCustomer and ExternalCustomer both have a one-way association to CustomerStatus) When saving the above model in the designer, I receive the error Entity CustomerStatus has multiple properties/associations named '' |
|
|
Thanks for catching this. It too will be fixed in the 11 Sept nightly. |
|