Conflicting overlapping column settings

Discussion of open issues, suggestions and bugs regarding Entity Developer - ORM modeling and code generation tool
Post Reply
mindplay
Posts: 148
Joined: Tue 13 Dec 2011 22:58
Location: Ithaca, NY

Conflicting overlapping column settings

Post by mindplay » Fri 10 Feb 2012 17:27

I don't recall if I already reported this, but one remaining issue in release 4.2.129, is that you are still allowed to have conflicting column settings.

That is, when you use table-per-inheritance-hierarchy mappings, you might map different properties on different classes to the same column.

Unfortunately, you can set the column-settings to NotNull=True for one property, and NotNull=False for another property that maps to the same column.

Which one determines the outcome (in terms of schema) appears to be somewhat random?

Ideally, modified column-settings should propagate to the column-settings of other properties mapped to the same column. (and when propagating changes, the code must take into account the effective column-name, not just the property-name.)

Alternatively, a validation error-message could be added, making you aware of the conflicting column-settings, which will lead to unpredictable schema changes...

mindplay
Posts: 148
Joined: Tue 13 Dec 2011 22:58
Location: Ithaca, NY

Post by mindplay » Tue 14 Feb 2012 14:41

This problem also affects schema updates - for example, I have a class with half a dozen subsclasses, and a couple of those subclasses (not all of them) have a property called "UseMailingAddress".

This property has a default value for the Column it maps to. Unfortunately, if you set the default value inconsistently, or forget to set it for one of the subclasses, the results are unpredictable.

(This isn't a different problem per se, just another example to demonstrate why it doesn't really work the way it's implemented.)

Shalex
Site Admin
Posts: 8240
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Wed 15 Feb 2012 13:15

This problem corresponds to the one which you reported at http://www.devart.com/forums/viewtopic.php?t=23233 (first problem).

As a solution, we are going to implement a merging of mismatched settings when determining column attributes in the database (without throwing any errors).

mindplay
Posts: 148
Joined: Tue 13 Dec 2011 22:58
Location: Ithaca, NY

Post by mindplay » Wed 15 Feb 2012 13:50

In my humble opinion, having multiple column-settings for a distinct column in the schema, is wrong. Simply coming up with a "better" way to avoid dealing with that problem doesn't exactly cut it.

I would strongly prefer inconsistencies being reported as errors, over some arbitrary conflict-resolution algorithm that I would need to keep in the back of my mind while working with ED... It will lead to troubleshooting sessions, where you have to play detective to try to figure out why the column-settings aren't coming out the way you expected.

But as said, I firmly believe the correct approach would be for conflicts to be resolved at design-time - by propagating the "latest" column-settings to other properties in the model that map to the same column. And I don't hear you making an argument against that? In my opinion, taking the easy way out on this one won't help make this product any better.

mindplay
Posts: 148
Joined: Tue 13 Dec 2011 22:58
Location: Ithaca, NY

Post by mindplay » Wed 15 Feb 2012 14:03

Besides, there are some conflicts you can't resolve. If one column says the type is INT and the other says STRING, how would you resolve that?

Sure, you could decide on some arbitrary SQL type priorities - say, VARCHAR has higher priority than INT, because you could store an INT value in a VARCHAR column, but ... the data in that table would be impossible (or at least difficult and slow) to query ... and what about the underlying types in the generated code? Are you going to change the type-declaractions in the generated code too? Because a String does not map to an Int32.

I hope you realize in time that you're about to open up a can of worms here.

Shalex
Site Admin
Posts: 8240
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Wed 15 Feb 2012 16:37

Thank you for posting. We will try to implement the approach when inconsistencies being reported as errors.

mindplay
Posts: 148
Joined: Tue 13 Dec 2011 22:58
Location: Ithaca, NY

Post by mindplay » Tue 21 Feb 2012 17:21

Please see important notes related to this subject here:

http://www.devart.com/forums/viewtopic. ... 8693#78693

Bear in mind, the solution has to work equally well for properties and concrete mappings, as well as for type-discriminator columns.

Post Reply