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, In our current project, we have found a scenario that while normal, has surprised us on how LS behaves. We have an entity called Project, which holds a collection of another entity related Site. This creates two properties in Site, one called Project, and another called ProjectId. When in WCF, we saw that the designer has the options of: 1- Generate Backreference Data Member Attribute (Project) 2- Generate Backreference Id Data Member Attribute (ProjectId) 3- Generate Collection Data Member Attribute (Sites) We decided to only generate 1 and 3, because we thought that ProjectId was superfluous. But we have discovered that if we try to set a Project to a Site, and then save, saving fails because ProjectId is set to 0. So we have in the end to set the Id to be able to save the entities back in the server. It would be nice if setting the reference set the id automatically (like what happens in a collection that doing site.Project = x also adds site to the collection in object x). Or if that's not possible, if the reference property was generated as readonly (because the setter is not very useful if the Id has to be set by hand). Or maybe there's something I have missed totally and I have understood the use of those options in the designer wrong. Regards! Vicente |
|
|
Hi Vicente, No you are correct in that the backreference Id will be required for updates, so we will look at updating the designer to automatically toggle this on when you toggle on the backreference property to avoid future confusion. For now you will just need to set this manually as you have found :)
Thanks! Jeremy |
|
|
"backreference Id will be required for updates"
You should consider changing the designer so that the backreference is not settable, and only the Id can be set. This would at least make the API mirror the usage requirements. (It'd be very nice if setting the Id would also populate the backreference with the appropriate Entity at that point, too...)
Having the Entity include a public setter when that does not work causes a lot of confusion.
-Reed |
|