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
|
this may have been covered in another forum post - but i can't find it, sorry.
I have EntityB : EntityA and EntityC : EntityA using STI. EntityB defines a non-nullable PropertyA. In the model PropertyA is non-nullable but in the db it must be nullable (because EntityC doesn't have a PropertyA, yet shares the same db table). It's really annoying that the designer is always telling me to either make the db column non-nullable or the model EntityB.PropertyA nullable. Can the designer relax the nullability checks for STI derived classes? Or at least give me some way of turning these off per entity via metadata or some designer flag - a sort of I-know-what-i'm-doing-just-shutup-and-skip-the-nullability-checks-for-this-entity? My current workaround for these has been to make PropertyB not nullable in both the model and the db and assign a sql default constraint in the db. But this kinda reeks - and doesn't work at all nicely for non-nullable DateTimes. Having a table littered with DateTime.Min just to maintain non-nullability in the model AND shutup the erroneous designer sync messages is going to look real ugly. And I have an awful lot of sql default constraints on STI tables that I don't need (but still have to maintain), just to shut up the designer sync. Any suggestions? I may have missed a really obvious way of handling this nicely. Or how about having something I can tweak in the designer so I can have both nullable db columns and non-nullable model properties without getting tons of false messages I have to wade through and ignore each time I do a model/db sync... thanks |
|
|
|
|
or even, how about relaxing the sync nullability checks per property? oh, and realised this post is probably related to this: https://www.mindscapehq.com/forums/Thread.aspx?PostID=12047 so see - if you allow us to tell the designer that we really do know what we're doing (turn off nullability checks per assoc or property) then you could kill off two problems in one hit. :)
|
|
|
|
|
just in case you're vacillating between addressing this one or not - this scenario (handling foreign keys and non-nullable properties on STI derived entities) is the single biggest pain and the reason why model/db sync really doesn't work for me. I imagine that this scenario is not uncommon for STI models of even moderate complexity so a fix would be a super duper thing. just sayin... ;) |
|
|
|
|
Okay, I've done some extensive vacillation and there will be an experimental version of this in the next nightly build. I'd very much appreciate you giving it a bit of a bash around because there might be some rough edges! You will notice that there is no "ignore nullability differences" option. In the end I felt that such an option would basically come down to a choice between "Bug me uselessly every time" and "Never bug me," which didn't sound like a useful choice to offer people! Perhaps in a future version we will be able to determine whether the database has changed since we last synced, which would allow us to bug people only when it was relevant, but we can't do that at the moment. Not that this would affect you anyway since you are updating the database from the model rather than the model from the database. Let us know how you get on! |
|
|
|
|
Sorry, I fouled this up and it is not actually in the current nightlies. It will be in tonight's nightly, though. |
|
|
|
|
np - and good timing! - was just about to grab the nightly and try it out. :) |
|
|
|
