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 All. I have another problem related to the use of BeginEdit() / CancelEdit(). I have an entity (by example Person) with a FK relation to another entity (by example House). In Person class are the fields: int houseId; EntityHolder<House> house: and the property House House: House is lazy loaded, however if I call BeginEdit() before House is loaded, when I call CancelEdit() House becomes null and house.IsLazy becomes false, so is never loaded again. .... // suppose tha person.House is not loaded, so is null and person.house.IsLazy = true person.BeginEdit(); House house = person.House; // house is loaded here .... person.CancelEdit(): // now person.House is null and person.house.IsLazy = false
It is neccesary access house.Person before calling BeginEdit().
... House house = person.House; person.BeginEdit(); .... person.CancelEdit(); // person.House is not null now
Maybe I am not using correctly BeginEdit() / CancelEdit().
Thank you. |
|
|
After much debugging the result is that calling CancelEdit() is very dangerous when there are relations, the related entities are lost forever, even when you make no changes in the entity. I can reproduce it using the same sample I sent you this morning. |
|
|
I uploaded a sample program to show the problem calling CancelEdit(). The sample is the same I sent you by mail to show the composite key problem. Hope this helps. Thank you. |
|
|
This appears to be a bug with lazy-loaded through associations. The workaround is to set EagerLoad on the EntityHolder members of the through class (UserGroup in your sample): [EagerLoad] We recommend doing this anyway because there is rarely any reason to load a through entity (e.g. a UserGroup) by itself: really, what you're always interested in is the "real" entity referenced by the through entity (e.g. the Group). So it is generally more efficient to automatically eager load the associated entity (LightSpeed will load the through entity and the "real" entity in one database hit rather than two). We acknowledge that this is a bug but because it appears to occur only in lazy-load scenarios, and we believe that there is no benefit in using lazy loading for through associations, we'll log it as low priority. If you disagree, we're open to feedback. We'll also look at whether the designer is generating lazy-load code in which case we should probably switch that over to eager loading. |
|
|
Thank you, that works! I will use the EagerLoad attribute. The class UserGroup was initially generated by the designer (I used the designer to initially create the model), but it's no problem to apply this attribute. I am porting a very big application from strongly typed datasets to LightSpeed, I am beginning, the are much code to review. At the moment all is OK, I like LightSpeed. |
|