The ORM Foundation

Choosing Text: Varying always produces an nvarchar column. Unfortunately, I need to match some varchar columns that already exist, and cannot change them yet. Is there something I can do short of editing the generated SQL?

John,

We just don't have the data right now to determine which type of char to produce. This is also the very last step in the generation--all previous steps produce XML.

The best way to change the generated code is to change the generator. To do this:

In Regedit:

1. Goto HKLM\SOFTWARE\ORM Solutions\Natural ORM Architect for Visual Studio 2005\Generators\DDILtoOracle (or the correspond Visual Studio 2008 key)
2. Export the key
3. In the exported registry file, change the key name, DisplayDescription, DisplayName, OfficialName (maintain no spaces), TransformUri (remember this for later) values
4. Save and import the registry file
5. Note the original file referenced by the 'TransformUri' registry value, and make a copy of the file into the new file name that corresponds to the 'TransformUri' property in the registry
6. Find 'CHARACTER (note the leading single quote) in the file and change the generated values
7. Find >N< (should be with character string literal) and get rid of the N line.
8. Save the file
9. Back in NORMA (you might have to reload), if you expand the 'Oracle'  entry in the ORM Generation Settings dialog, you'll now see your new generators.

Note that you can have a much smaller XSLT override file by using an xsl:import statement against the original file. Just override the four templates changed above. Note that you'll need to grab the characterStringLiteral template from DDILtoSqlStandard.xslt. This will also let you pick changes up in the original file when NORMA is installed/uninstalled.

From a metamodel perspective this is an interesting problem. Basically, the generation targets need the ability to specify additional facet information on the datatypes that applies to this generator only, but is not a conceptual issue. Terry and I have been looking at metamodel options for datatypes to replace the placeholders we have now. These will allow user-defined datatypes and facets, compound and abstract data types, and a few other fun things. I hadn't considered this issue in a while, but will look at ways to support this type of mapping option as well. Theoretically, this could be different for different columns, so is not something that should be set globally.

Don't hold your breath on this one. A wholesale rework of datatypes is relatively high on the list, but it will be at least a couple of months before I'll even have a change to look at it. Hopefully this will keep you going until that time.

-Matt