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
|
We are having an issue where calling BeginEdit is causing massive application slowdown. Basically when we add a new Contact record, then call Begin Edit, it runs through all related records contained in the back Reference. Now I'll attempt to explain the scenario... We add a new Contact, Add an Existing Status to the Contact, Call BeginEdit, Then BeginEditInternal goes through the Contact fields, follows StatusID to the Status record, goes through the status fields, then follows the back reference and iterates through all of the Contacts with that StatusId, this goes on for many more relationships and causes the Action to take over 15 seconds to execute. Any guidance you can provide on alleviating this issue would be most appreciated. Thanks |
|
|
|
|
Its slow because those associations are being lazily loaded I presume leading to the data being fetched as you start BeginEdit? If thats the case you should either look at loading the hierarchy eagerly using named aggregates or by marking the associations as eager loaded so the [EagerLoad] attribute is applied generally.
|
|
|
|
|
It's hitting hundreds (will eventually be 100's of thousands) of records on the back reference which has no relation to the record being saved other than sharing a status. Is there a way to tell Begin edit to not follow back references? |
|
|
|
|
No, its intended for this to load back references because we need to track the child collections as well as the state of the parent object to rollback everything. Ill have a look to see if there is anything we can do to allow this to work in a deferred manner and let you know if we can make any changes here.
|
|
|
|
|
Do the calls to toOneModel.GetHeldValue(this) and toManyModel.GetEntityCollection(this)/LoadCollection(value, this) trigger the load of Lazy Loaded entities/collections? |
|
|
|
|
Yes both of those will trigger a lazy load if required.
|
|
|
|
|
Is there any way that the BeginEdit can identify that a lazy loaded collection/Entity has not been loaded and store that in the backup, then a CancelEdit would restore the collection/Entity to the unloaded state if it was modified during the edit? We have one case where we modify a status and 100,000 UserAccounts are being loaded; this makes the application very slow and causes unneeded load on the database server. |
|
|
|
|
Im currently working through testing a change to support this via a compatibility option on the LightSpeedContext. All going well we should be able to get this merged in tomorrow so you can test this locally. Ill post another update once this is merged in for the nightlies.
|
|
|
|
|
Great news! I truly appreciate all the help and support that you provide for us. Will this be an independent compatibility option, or will it be tied to EnableCandidateFixes? |
|
|
|
|
Initially it will be tied to EnableCandidateFixes so you can check this against your solution, if we are happy with how this is working I will look at moving the option to something a bit more explicit as a permanent solution.
|
|
|
|
|
Hi Jason, Just following up on this - I notice I didnt actually indicate that this is now the the nightlies - let us know how this is going for you once you have had a chance to update and test this out.
|
|
|
|
|
This worked beautifully! Thanks again. |
|
|
|
|
Thanks for the update, I will look at migrating this away from the compatibility option at a later stage and Ill post an update when we are looking to change this and what changes will be needed to migrate this.
|
|
|
|
