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, I'm evaluating Lightspeed to replace our old ORM. I'm getting the error that circular associations are not supported. In this case an employee is member of a department, which has a manager (who is also an employee). So there is employee.departmentId and department.managerId. I wouldn't expect this to be a problem, because I don't think Lightspeed will be prefetching all of these objects (and making an endless loop), only after asking for it. Is there a way to work around this? Lightspeed is looking promising but we really need this to work. |
|
|
Unfortunately no, this is not supported. The issue isn't the endless prefetch loop, it's figuring out the order in which to perform inserts and deletes. LightSpeed works out the order at the table level, using the principle that if Table A has a foreign key to Table B, then Bs have to be inserted before As. Obviously, if B also has a foreign key to A, then As have to be inserted before Bs. So LightSpeed can't work out a consistent order. It is possible to break this by implementing one of the associations manually instead of using a LightSpeed association. For example, create Department.ManagerId as a plain integer/GUID field, and implement Department.Manager and Employee.ManagedDepartments as handwritten queries e.g. partial class Department { Some care is required with this approach (for example, you need to ensure that all entities are assigned to a UOW, and therefore have their IDs allocated, before wiring them up). Note that you can still represent the association in the designer so as to get database sync, you just need to set Generation to None and implement the FK field and association properties in the partial class. We're aware that there is scope for LightSpeed to be a bit smarter about this -- unfortunately we don't think it's a quick fix so for now we can only suggest the workaround. |
|