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 many-1 assoc with EntityX. EntityC has a many-1 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). EntityXId and EntityYId are nullable - although they are not-nullable from the perspective of the derived entities they are used for, because they are only relevant (and populated) for certain subtypes of EntityA. (running off a recent build - 9th sep i think) the behaviour i'm seeing is this:
When I sync the db from the model it wants to change the above mentioned FK columns to not-nullable. From the model perspective, the associations (eg EntityB has a 1-many assoc with EntityX) are not nullable. But from a db perspective the columns must be nullable because the table is shared. I tried to get around this by making the 1-many associations nullable - but of course this doesn't work because now I have (for eg) a nullable EntityB.EntityXId which is no good. In my model, EntityB must have an EntityX.
As it stands, I have to just ignore these suggestions from the designer. Any chance of adding some smarts to handle this case for many-1 associations on derived STI entities? (and i know, i know, please don't tell me to use class table inheritance - way too far down the track for that!!) cheers justin |
|
|
I've logged a feature request for this, but there are some difficulties with it, so it probably won't happen in the near future. (One of the problems is that, with this change, if we see a nullable FK in the database, we won't know whether the nullability of the FK is meant to represent 'not dependent' or 'dependent, but not used in all derived types,' so won't be able to warn if the association in the model has incorrect nullability.) Sorry. |
|