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
|
I am running into a problem with Lightspeed. Whenever I create a 1 - many association, Lightspeed creates both the back reference and the collection. In many cases, I don't want the collection to be created. Sometimes this is simpily for tidyness reasons, if I never want to reference the collection then there is no need to show it. A more serious problem comes when I try to use the objects for in ajax. The presence of both the reference and the collection creates a circular reference which then causes problems with json serialisation. I end up either hand coding the reference, or creating view models. Ideally I wouldn't have to do this, just tell Lightspeed not to create the collection Thanks
Sean |
|
|
|
|
The simplest solution to this is probably just to keep the private EntityCollection field, but get rid of the public EntityCollection property. Then the collection would exist, which would keep LightSpeed happy, but it would be out of sight, so wouldn't clutter up your API, and would presumably be ignored by your JSON serialiser. (This assumes that your JSON serialiser considers only public properties rather than private fields, of course.) If, however, you are really determined to get rid of the collection altogether, you can do this in nightly builds dated 25 March and above by applying the NoReverseAssociationAttribute to the EntityHolder. (Note that this is not supported in the designer, only in handwritten code.) Be warned, though, that the primary use case for NRAA is reference data. If an EntityHolder has NRAA, this can cause additional queries to the database unless the target type of the EntityHolder is set for caching. So please profile carefully if using NRAA just for API cleansing. |
|
|
|
|
Is there any way to delete the public EntityCollection property in the designer? NRAA looks like what I need actually. Will that be added to the designer any time soon?
Ta Sean
|
|
|
|
|
The designer can't delete the EntityCollection property on its own, but you can set the association's Generation to FieldOnly. That will also suppress the other public properties (the entity reference and foreign key), but you can easily recreate those in the partial class. I wasn't really planning to add NRAA to the designer because it's what Alan Cooper calls an "ejector seat lever" and I think it would be dangerous to display it alongside routine settings like the property names -- people would be tempted to set it for no good reason and without understanding the requirements around it. (The danger arises because it would *appear* to work -- until they put it into production where the performance impact would suddenly show up.) If we ever get round to implementing an "Advanced Settings" dialog where we can hide the ejector seat levers then we could put it there, but otherwise I can't think of any safe way of surfacing this option. Open to suggestions! |
|
|
|
