Menu
▾
▴
#5 Ring Constraint .OIAL.xml error
Hi,
A more complicated NORMA model was generating highly
truncated .sql files using ORMCustomTool. I pared
down the model to try to isolate the cause. I think
this very basic test model's ring contstraint is the
cause of the problem. It generates an .OIAL file with
the following error: Warning 1 There is a
duplicate key sequence 'Patriarch_Patriarch_name' for
the 'http://schemas.orm.net/OIAL:conceptTypeChildKey'
key or unique identity constraint.
I don't believe there is a flaw in the way I used
the ring constraint, and there was no error in the
list for the model file before mapping.
I'm trying to attach the .orm file for you to test.
If that doesn't work, here's the gist of it:
Entity type: Patriarch (Name,
Binary fact type - reading: "fathers" with UC
over 2nd role, both roles connected to Patriarch,
Ring Type as AsymetricIntransitive applied to
roles 1 and 2,
Objectified as "Issue",
Issue playing unary fact type.
Please let me know if the file attaches for you.
Also, if there is a work-around; I do like ring
constraints. BRN..
Very simple,ORM file that generates .oial error
Logged In: YES
user_id=1014759
The file came through fine.
Currently, the tool is not enforcing the rule that far
role names for an object type must be unique. Try giving
each of the roles in the fact type a unique name. Is the
code generated after this change any better?
Logged In: YES
user_id=1501525
Hi,
Naming the roles in the objectified predicate 'sire' and
spud' didn't resolve the issue. There's still the warning
message in the .oial file, and when I run the DDL script
for SQL Server, itcomes back with an error message about
two columns 'Ptrrch_Ptrrch_nm' having the same name. At
least this time, the unary fact type I attached to the
objectified predicate showed up in the .sql file - it
didn't get down that far before. So, naming the roles
helped, but didn't resolve the issue. I can try altering
one of the column names in the CREATE script directly.
That should work, but still a kludge. I'll also try naming
more roles and facts in the model, see if that helps. Let
you know. Glad the file transfer worked. BRN..
Logged In: YES
user_id=1014759
The problem is that there are hidden implied fact types
behind the objectification, and the names of these are not
being correctly updated when the equivalent roles in the
objectified fact type are changed. We are working on
several aspects of the objectifications right now, and
we'll make sure that this gets fixed as part of that
process.
In the mean time, if you manually edit the .orm file in a
text or XML editor, you should be able to specify names
for the roles under the appropriate "orm:ImpliedFact"
elements.
Logged In: YES
user_id=1501525
Hi,
Thanks for suggestions. I just tried changing the names
for the columns and the ICU8 constarint (missed that the
first go-round), in the .sql file. The generated SQL
Server Database looks normal. Adding sample data to the
table revealed one flaw; while it wouldn't let a spud have
more than one sire, it did let Issac father Abraham, after
I had started with 'Abraham fathers Issac'. Seemed to miss
the 1st 'Patriarch' I entered into the table.
I'll follow your suggestions and play around a bit more.
Hope this kind of feedback helps. BRN..
Logged In: YES
user_id=1501525
Hi,
Adding names to the orm:ImpliedFact roles did work -
looks like only the first role name for each fact type was
used in the mapping. The AsymetericIntransitive constraint
still failed to catch the 1st instance of the population
listed (Abraham still can have Joseph for his father). The
constraint seemed to catch the rest.
Beside getting a fix for the problem, looking at the .orm
file with an XML editor was quite interesting. Thanks for
the suggestion. I'd recommend it to all the testers. BRN..
Logged In: YES
user_id=1501525
Hi,
Also see that you can enter the role names for these in
the properties window, by drilling down through the ORM
Model Browser (once you know under which FactType to
look). That's a bit easier than finding the spot in the
XML. BRN..