From: SourceForge.net <no...@so...> - 2006-04-27 04:32:19
|
Bugs item #1477049, was opened at 2006-04-26 11:10 Message generated for change (Comment added) made by brian27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1477049&group_id=158881 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Nalewajek (brian27) Assigned to: Nobody/Anonymous (nobody) Summary: Ring Constraint .OIAL.xml error Initial Comment: 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.. ---------------------------------------------------------------------- >Comment By: Brian Nalewajek (brian27) Date: 2006-04-26 23:32 Message: 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.. ---------------------------------------------------------------------- Comment By: Brian Nalewajek (brian27) Date: 2006-04-26 17:14 Message: 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.. ---------------------------------------------------------------------- Comment By: Kevin M. Owen (kevinowen) Date: 2006-04-26 16:43 Message: 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. ---------------------------------------------------------------------- Comment By: Brian Nalewajek (brian27) Date: 2006-04-26 16:36 Message: 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.. ---------------------------------------------------------------------- Comment By: Kevin M. Owen (kevinowen) Date: 2006-04-26 15:04 Message: 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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1477049&group_id=158881 |