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. We’re experiencing a really heavy select query that executes when we edit an entity property from an entity collection. Our scenario is this - We load a collection of appointments. Each appointment has a one to one link to the appointmentType table. Some appointments are linked to appointmentTypeId x but none are linked to y. When we edit one of the appointments and set the appointmentTypeId to y then everything works fine. But when we change the appointmentTypeId to x then we see that a select query is run (query (select appointments appt where appt.appointmentTypeId = x) Unfortunately this query can return over 600,000 results and we get a nice out of memory exception. So to clarify, It works fine if we set the appointmentTypeId to a value that no other appointment is linked to within our collection but if we set the appointmentTypeId to a value that another appointment is linked to then Lightspeed generates a select query and we get the exception. Is this normal? Any ideas?
|
|
|
We have a known issue where setting the foreign key of an EntityHolder can result in loading the EntityCollection of the reverse association (it relates to ensuring the EntityCollection reflects changes that haven't been flushed to the database yet and it's not a trivial fix). The way around it is to make the association one-way, so that the Appointment has a reference to the AppointmentType but the AppointmentType does not have a collection of all Appointments. You can do this in the designer by just setting the collection name on the association arrow to an empty string. However, at the moment we only support this for reference data scenarios, where the target type can be cached. In your case, that means you would need to set the AppointmentType entity as cached if it isn't already. It sounds like the set of AppointmentTypes would be mostly static so hopefully that won't be an issue. (We are working on improving our support for one-way associations, and we do hope to tackle the issue of unnecessary collection loads at some point -- but resources are tight at the moment and we can't commit to anything.) |
|
|
Hi. Wondering if you have made any improvements in this area in the last 4 months? While our initial problem was helped by your suggestion, we now have another similar issue where we can't set the parent object to be cached as was suggested. Cheers. |
|
|
No unfortunately there have not been any updates to this and we dont have any current plans to make changes to this due to the amount of effort required. Is this new situation the same as before with the difference that you cannot apply the caching approach or is it different?
|
|