Suppose this schema, when Person is not independent:
Person(name) has favorite Animal(name)
Person(name) has favorite Book(name)
The DDL does not enforce the fact that for each Person at least one fact must be recorded. Obviously this is tough to implement if some Person facts appear in another table.
Sorry, I made a mistake. The schema is:
Person(name) has Age()
Person(name) has Nickname()
All roles are optional but Person is not independent.
Note sure what you comment or question is about. Did you find a fault or unexpected result in a DDL script when you used NORMA's custom tool to create a schema? Were you looking at the physical implementation (as for MS SQL Server 2005), or just the DDL or DDIL files produced by the tool? BRN..
the DDL script for sql server does not have a constraint that requires the age or nickname column to be non-null, which is probably a bug or non-yet-implemented feature.
You're correct, this is incorrectly spitting as if it were Independent. Without setting IsIndependent, ORM theory states that the set of played roles (excluding the roles participating in the primary uniqueness relationship) are disjunctively mandatory. For this case, where there are two optional functional roles, we would still make them optional in the table, but would also generate an additional check constraint to enforce the disjunctive mandatory (your last point).
For the previous case, where you had a single functional role, the column should not end up as optional.
Note that, while the set of unenforced ORM validation errors is shrinking, we haven't bottomed out yet. We are not currently enforcing that IsIndependent can only be set when all non-existential roles are optional. After some offline discussion here, we think it would be easiest to just enforce the pattern without the validation error (IsIndependent will turn off when it is no longer valid, and be read-only when it cannot be turned on). In the meantime, please be very careful about setting IsIndependent to true.
PS We don't deal well with IsIndependent on a Subtype, so please don't try it right now. Visio allows you to set this by automatically turning on the 'Generated as Separate Table' option. We don't consider this option part of Core ORM, but will add it as an extension property with the live absorption layer we're working on.
PPS We do have a preliminary Relational View. To see it, turn on 'Relational View' in the Extension Manager (on the context menu), then right click in the diagram tab row and add a new 'Relational View' page. There are a lot of caveats on this page (there is a perf hit from the mapping fully regenerates on ANY model change, the column names will be different than those in the generated DDL, and customizations are not propagated to the generated DDL). We're working on making the customizations persistent and the mappings view incrementally live, but this is a non-trivial task. Turn off both the 'Relational View' and 'ORM Intermediate Abstraction Language' extensions to get your performance back.
Tried the preliminary Relational View page option. It covered a few additions and changes to a simple model well, but the performance hit was noticible (as you warned). Still, more useful functionality - but odds are I wouldn't have spotted it or gotten to it without the explicit instructions in the reply to the original poster. BRN..
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.