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
|
I've got a model using STI inheritance. EntityB : EntityA EntityC : EntityA EntityB has a 1-many assoc with EntityX. EntityC has a 1-many assoc with EntityY. EntityA is abstract. This is modeled in the db as a single STI table for Entities A-C. And that table has FK refs to tables X and Y (on columns EntityXId and EntityYId respectively). Everything is actually working correctly at runtime. But the model sync wants me to delete these associations. Looks like the sync logic is not managing to work out that the associations are actually handled by derived classes, not the abstract base class. Would be great to have model sync handle this - then i think it's all 100% working for model/db sync for me... :D cheers justin |
|
|
This is working okay for me. And since it's asking you to delete the associations on the derived classes rather than add associations on the base class then I believe it has worked out that the associations are handled by the derived classes but isn't seeing them represented in the database. Are you sure that EntityXId and EntityYId have foreign keys on them? Can you provide me with a small repro example? Thanks! |
|
|
If the FKs do exist in the database, one more thing to check: I recall we saw a case where FKs existed in the database but were not mapped to associations because the target table's primary key column had a unique index on it as well as the primary key. SQL Server was reporting the FK as being against the unique index rather than the PK, which meant we couldn't locate the target table and map it to an entity. So it might be worth checking if this is the case for your EntityX and EntityY tables. The unique index in this scenario is redundant and probably spurious, and can be removed. |
|
|
ok, well that's sort of embarrassing. i can't even repro my own bug report. anyhow, maybe i'm confused as to exactly what the problem is/was - but there is an issue closely related which you may be able to help with - will create separate post for this... consider this thread not-repro... :|
|
|
|
actually the issue was probably i misrepresented the model to you. the 1-many association was round the other way. never mind. |
|