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
|
Hello again, Noticed a problem when deleting an entity that is a descendant in a Class Table Inheritance hierarchy. I'm using the IUnitOfWork.Remove(Query) method with an Identity query to identify the entity to remove without hydrating the entity first. The generated SQL only includes a delete statement against the descendant table, but doesn't delete the record from the base table - leaving the entity in an inconsistant state. Any chance the IUnitOfWork.Remove(Query) method can support CTI too?
Cheers, |
|
|
Thanks for drawing our attention to this. Unfortunately, this doesn't look like a quick fix: I will log a bug for it but I think you are going to be better off implementing a workaround rather than waiting for a fix. (The difficulty, by the way, is not with propagating the delete up the inheritance hierarchy to the base class; it is with propagating it down to derived classes, specifically because LightSpeed may not be aware of those derived classes. This is because the LightSpeed runtime becomes aware of derived classes only when they are used -- it doesn't have access to the designer model, and it doesn't poke around speculatively looking for derived classes.) The workaround is to call Remove(new Query(type) { Identifier = id }) for each base and derived type of the actual type (in addition to the actual type itself). So something along the lines of: // Works for any type in the Player hierarchy Since I believe you are customising your designer templates already, you could probably arrange to have this method generated for each type that is the root of a class table inheritance hierarchy, which would avoid the maintenance issue as you added new derived types. Obviously there is also scope for optimisation based on passing in an actual type (e.g. if the Remove is for a Cricketer then you'd issue Removes for Player and Bowler but not for Footballer), though this is probably not worth it unless you have a very deep or wide class hierarchy. |
|