The ORM Foundation

I have a bunch of these errors on the MyModel.CoRef.orm diagram when I am trying to generate a build.

These errors are on the generated CoRef.orm diagram.  For example,

" At least one reading is required for fact type 'OrganizationOrganization_isnonprofit' in model ''.	ORMModel1.CoRef.orm "

OK... I am confused.  What more can I give it for a reading?  I look at the reading editor but I can't change the reading?

And in the properties, OrganizationOrganization_isnonprofit ends up being the role name.

On the original orm diagram, this is a unary, Org.... IsNonProfit. (Check Yes or No, like in country song)

I have to go for now.  If you any thoughts on this, they would be much appreciated.

Jason

This is a bug having to do with unaries in the orginal ORM diagram, and I will be reporting it as such.

Until then, here is why the OIAL to DCIL bombs out.

#error Exception occurred while executing transform 'OIALtoDCIL'. The existing contents of 'ORMModel1.DCIL.xml' will not be modified.
// System.ArgumentNullException
// Value cannot be null.
//Parameter name: name
//    at System.Xml.Xsl.CompiledQuery.Script1.makeValidIdentifier(String name, Int32 maxLength)
//   at System.Xml.Xsl.CompiledQuery.Script1.makeValidIdentifier(String name)
//   at <xsl:template match="oil:model">(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime, XPathNavigator {urn:schemas-microsoft-com:xslt-debug}current)
//   at <xsl:apply-templates>(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime, XPathNavigator )
//   at Root(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)
//   at Execute(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)
//   at System.Xml.Xsl.ExecuteDelegate.Invoke(XmlQueryRuntime runtime)
//   at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlSequenceWriter results)
//   at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter writer, Boolean closeWriter)
//   at System.Xml.Xsl.XmlILCommand.Execute(XmlReader contextDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter results)
//   at System.Xml.Xsl.XslCompiledTransform.Transform(XmlReader input, XsltArgumentList arguments, XmlWriter results)
//   at Neumont.Tools.ORM.ORMCustomTool.ORMCustomTool.XslORMGenerator.GenerateOutput(BuildItem buildItem, Stream outputStream, IDictionary`2 inputFormatStreams, String defaultNamespace) in c:\Documents and Settings\mcurland\My Documents\Visual Studio 2005\Projects\ORMPackage\Tools\ORMCustomTool\XslORMGenerator.cs:line 224
//   at Neumont.Tools.ORM.ORMCustomTool.ORMCustomTool.GenerateCode(String bstrInputFileContents, String wszDefaultNamespace, IVsGeneratorProgress pGenerateProgress, WriteReportItem report) in c:\Documents and Settings\mcurland\My Documents\Visual Studio 2005\Projects\ORMPackage\Tools\ORMCustomTool\ORMCustomTool.cs:line 575

Hi,

I'm not good enough at this to see where an error might be without having the model in front of me (one reason the community really needs a site that allows people to post .orm files for others to look at).

There's one thing you mentioned that might have a bearing on part of your issue.  You wrote:

    "On the original orm diagram, this is a unary, Org.... IsNonProfit. (Check Yes or No, like in country song)"

Unary FactTypes aren't yes or no switches, they are yes only.  Only instances that play the role of being nonprofit are included in the population for that FactType.  You could (but it would be irrational in your UofD) have another unary FactType "IsForProfit" and have the same "Organization" play both unary roles!  You wouldn't do that because it violates the logic of your UofD (I hope), but it wouldn't violate ORM principles.

You probably know this, and it may well not be the cause of the problem you are having; but it can't hurt to think through your model and see if you are looking at it from the ORM perspective - rather than a programming, flow control perspective.

BRN..

If you send me the original ORM file, I can try to debug this for you and get you a fix for it. You should be able to send it as an e-mail attachment to my SourceForge e-mail address (kevinowen {AT} users {DOT} sourceforge {DOT} net).

Brian-

Good catch.  In our case, we only care if it is a nonprofit for that fact.  Another example: person isdeceased.

To duplicate this error at home, try making a single unary on a new document and then generate a build.

I have webspace avail... I would be willing to host files... not sure how to implement off the top of my head...

I also noticed another post of yours... this bug is another reason for establishing test cases for the community to use in helping to evaluate new releases if the team deems that helpful.

>>and see if you are looking at it from the ORM perspective - rather than a programming, flow control perspective. 
 
Thanks for pointing out the potential ORM issue.  Luckily I know the ORM is right... I didn't design it. (but yes, I do need to improve my ORM skills!  And I will! )

Have a good one!  

Jason

OK, the problem appears to be that the model itself doesn't have a name. We use the model name as the basis of the SQL SCHEMA name.

Once I added a model name through the Properties window while the diagram was selected (i.e. just click on the white "background" outside of any fact types, object types, etc.), everything appears to have generated correctly.

Do you know if you cleared the model name at some point? By default, the model should always have a name (although precisely what that default name will be depends on which mechanism is used to initially create the model file).