I changed MAX_IDENTIFIER_LENGTH in the javascript function makeValidIdentifier in
Common Files/DIL/Transforms/DILSupportFunctions.xslt without any effect. This
function uses various strategies to produce sane-length identifiers from a long
name, but changing the MAX_IDENTIFIER_LENGTH didn't seem to affect any of the
generated symbols.
I was hoping to get long table names, as some of them come out as lists of initial
capital letters only :-(.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, the number is in three places now. We'll look at putting it back to one. Kevin has a couple of other tweaks he says he wants to make in this file.
1) Look for '= 30' (this the one you found)
2) Look for {0,29} (there will be two of these, change the upper bound)
That should take care of the issue. A VS restart will be needed to pick up the change (we have a file watch on the top-level files, but not he imported ones).
Sorry about the inconvenience on this one, the fix is admittedly on the obscure side. -Matt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-02-06
Cool, thanks for that. This is the kind of thing that would be good to have as a parameter to the model itself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, we need to do something here, but we haven't quite decided where to put the setting. The problem is that the correct value is dependent on the target DBMS, but we don't know what that DBMS is until the leaf transforms of the generation path are run (several steps after the names are determined). We could do something like a 'requested length' at the DBMS stage and then raise a generation exception (shows up as a compile error) if the names end up too long for the DBMS.
Anyway, we know this is an issue, and is one we intend to look at after the OIAL mappings are persistent. It is not a conceptual setting so does not really belong in the core model. -Matt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-02-06
> It is not a conceptual setting so does not really belong in the core model
Well, the diagrams aren't either, and neither really is the "isExternal"
boolean, yet they find a place in the file - just not in the model itself.
Perhaps it would be best to have the generator settings in a third section
of the file, rather than stored inside the VS project.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe there is a conceptual quality in the isExternal property. One of the great things about Service-Oriented Architecture is the way it allows you to build an infrastructure of shareable information. Such an infrastructure technically consists of a number of entity services, where the mission of each entity service is to be the only authoritative source of data belonging to a specific information area. An information area is a business subject such as customers, vendors, products, finances to mention a few examples.
When you plan the information content of an entity service it's a good idea to start by doing a conceptual information model of the information area the service is supposed to be responsible for. When you do that, it's unavoidable that some of the objects which belong to the information area in question need to be related to objects which don't belong to the same information area. These objects should be included in the model, and they should be marked as being External. This is why I think it's a very good thing to have such a property.
The reason for this contribution is that I firmly believe that most of us will increasingly be involved in service-oriented context. Service-orientation is very much about establishing a business architecture and then modeling a service-architecture based on that business architecture. Therefore, the more methodologies such as ORM are aware of the great difference in system thinking made available by SOA, the better it is for us all.
/Sten
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-02-06
Sten,
I don't really disagree about isExternal - but to me, it's a pity that we have to
declare the degree of open-ness of our open world assumption. In other words, I'd
rather that tools make an assumption that the world is open unless declared otherwise.
The RMap procedure doesn't necessarily allow this, as Matthew alluded to when talking
about object orientation, so we're somewhat limited... but, read on...
I tackle it using aspect oriented design. There is a global aspect, which typically
contains only sub-aspects, which in turn contain objects and sub-aspects. Cross-
aspect references are allowed, but each object has a home aspect. The tools apply
only to one subtree of the global aspect hierarchy at a time, but can see that
there exist objects (and perhaps some things about those objects, like PRM) which
are outside the current aspect of interest. These "open world" references must be
treated conservatively, and aren't regarded as belonging in the current schema
though they affect the way it's modelled. In this way, external references have an
explicit referent, so there is no need for implicit referents.
I think ORM2 needs this concept of nested aspects. I'd like to see each diagram in
a model being allocated to an aspect (perhaps more than one diagram per aspect),
and objects that are currently tagged as external are required, before generation,
to be allotted to another aspect. Objects in another diagram of the same aspect
perhaps don't need to be distinguished. In any case, generation of a schema can now
proceed with one aspect and its subaspects, creating separate namespaces in both
schema and code. At least, that's what I've used successfully in my designs and
code generation in the ManageSoft products, which together total nearly 600 tables
and over 600,000 lines of source code in C#, C++ and SQL. That scale needs a good
namespace implementation to manage it!
As an example, I have an aspect "Directory" which contains Users, Computers,
Organization structure, etc for an organization. The Compliance Manager product
needs to extend these tables, in what is essentially a subclass relationship,
while using the base product's Directory features. The schema mapping of this
cross-aspect subclass relationship is affected by the fact that it's cross-aspect.
Absorption and partition are invalid mapping options. That's what I meant by
"conservative" mapping.
Clifford Heath.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Absolutely. There's a big difference between the core model and the xml file. The .orm files have a dummy root element (ormRoot:ORM2) that is a container for the 'real' information. The only special thing we do with this root element is provide an xml namespace mapping for all loaded domain models. Two of these are mapped automatically (ORMCore, ORMDiagram), the others are loaded as registered extensions. Although this is slightly non-standard from a pure XML perspective, where you can introduce namespaces at any node, there are a several advantages:
1) DSL domain models are loaded dynamically via .NET attributes, and the model cannot be extended after element population begins. Putting all of the namespace associations up front allows us to pull in the necessary models without walking the entire file.
2) The XML ends up much cleaner if you aren't constantly defining namespaces
Inside the root element we simply serialize all top-level elements from any loaded models. There is a natural hierarchy here (ORMDiagram references ORMCore, but not vice-versa). Top-level elements are determined by casting the domainmodel classes to IORMCustomSerializedDomainModel and asking for root elements (the implementation of the interface is generated. It is also likely to be renamed at some point and moved to the 'Framework' section given that there is nothing 'ORM' specific about it).
So, one option for adding additional information to the model file is to provide root elements in an extension domain model.
The other build in mechanism is through the extension framework. At the XML level, you'll see an orm:Extensions element with additional information relating to the ORM element. This allows model decoration without top-level extension and has some nice internal features (properties can mocked up on the fly for the Properties Window until you enter something other than the default settings).
A nice example of using extension properties is the 'Custom Properties' extension, which allows you to add typed properties to different parts of your model. Custom use both the Extensions element and root elements for serialization. [The property definition launch is hacked in right now, it appears as a checkbox on the Extension Manager dialog, but will be moved as an extension property on the model.]
The eventual goal here is associate extensions with different cross-cutting generators. All of our generation transforms spit transformable xml, which means that the generated 'code' itself is easily transformed, allowing the code to be modified without touching the primary transforms. We'll be adding support to our ORMCustomTool generation pipeline for cycling within a format (currently you progress between formats) to support this type of operation. I'd like to push this part of the project harder next quarter. The 'generator settings' (which generators you apply to the file) are separate from the extension data stored in the file. So, while we will add configuration settings to the generators to require certain extension elements, the choice of which generators to run against the model file will remain a project setting, not part of the model file.
Hopefully that gives a better understanding of what I mean by 'core model'. We are not locking anyone out of the main file in any way. In fact, we're trying to make the party as open as possible.
-Matt
PS I've hidden the IsExternal property until we do something real with it (in changeset 956)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I changed MAX_IDENTIFIER_LENGTH in the javascript function makeValidIdentifier in
Common Files/DIL/Transforms/DILSupportFunctions.xslt without any effect. This
function uses various strategies to produce sane-length identifiers from a long
name, but changing the MAX_IDENTIFIER_LENGTH didn't seem to affect any of the
generated symbols.
I was hoping to get long table names, as some of them come out as lists of initial
capital letters only :-(.
Unfortunately, the number is in three places now. We'll look at putting it back to one. Kevin has a couple of other tweaks he says he wants to make in this file.
1) Look for '= 30' (this the one you found)
2) Look for {0,29} (there will be two of these, change the upper bound)
That should take care of the issue. A VS restart will be needed to pick up the change (we have a file watch on the top-level files, but not he imported ones).
Sorry about the inconvenience on this one, the fix is admittedly on the obscure side. -Matt
Cool, thanks for that. This is the kind of thing that would be good to have as a parameter to the model itself.
Yes, we need to do something here, but we haven't quite decided where to put the setting. The problem is that the correct value is dependent on the target DBMS, but we don't know what that DBMS is until the leaf transforms of the generation path are run (several steps after the names are determined). We could do something like a 'requested length' at the DBMS stage and then raise a generation exception (shows up as a compile error) if the names end up too long for the DBMS.
Anyway, we know this is an issue, and is one we intend to look at after the OIAL mappings are persistent. It is not a conceptual setting so does not really belong in the core model. -Matt
> It is not a conceptual setting so does not really belong in the core model
Well, the diagrams aren't either, and neither really is the "isExternal"
boolean, yet they find a place in the file - just not in the model itself.
Perhaps it would be best to have the generator settings in a third section
of the file, rather than stored inside the VS project.
I believe there is a conceptual quality in the isExternal property. One of the great things about Service-Oriented Architecture is the way it allows you to build an infrastructure of shareable information. Such an infrastructure technically consists of a number of entity services, where the mission of each entity service is to be the only authoritative source of data belonging to a specific information area. An information area is a business subject such as customers, vendors, products, finances to mention a few examples.
When you plan the information content of an entity service it's a good idea to start by doing a conceptual information model of the information area the service is supposed to be responsible for. When you do that, it's unavoidable that some of the objects which belong to the information area in question need to be related to objects which don't belong to the same information area. These objects should be included in the model, and they should be marked as being External. This is why I think it's a very good thing to have such a property.
The reason for this contribution is that I firmly believe that most of us will increasingly be involved in service-oriented context. Service-orientation is very much about establishing a business architecture and then modeling a service-architecture based on that business architecture. Therefore, the more methodologies such as ORM are aware of the great difference in system thinking made available by SOA, the better it is for us all.
/Sten
Sten,
I don't really disagree about isExternal - but to me, it's a pity that we have to
declare the degree of open-ness of our open world assumption. In other words, I'd
rather that tools make an assumption that the world is open unless declared otherwise.
The RMap procedure doesn't necessarily allow this, as Matthew alluded to when talking
about object orientation, so we're somewhat limited... but, read on...
I tackle it using aspect oriented design. There is a global aspect, which typically
contains only sub-aspects, which in turn contain objects and sub-aspects. Cross-
aspect references are allowed, but each object has a home aspect. The tools apply
only to one subtree of the global aspect hierarchy at a time, but can see that
there exist objects (and perhaps some things about those objects, like PRM) which
are outside the current aspect of interest. These "open world" references must be
treated conservatively, and aren't regarded as belonging in the current schema
though they affect the way it's modelled. In this way, external references have an
explicit referent, so there is no need for implicit referents.
I think ORM2 needs this concept of nested aspects. I'd like to see each diagram in
a model being allocated to an aspect (perhaps more than one diagram per aspect),
and objects that are currently tagged as external are required, before generation,
to be allotted to another aspect. Objects in another diagram of the same aspect
perhaps don't need to be distinguished. In any case, generation of a schema can now
proceed with one aspect and its subaspects, creating separate namespaces in both
schema and code. At least, that's what I've used successfully in my designs and
code generation in the ManageSoft products, which together total nearly 600 tables
and over 600,000 lines of source code in C#, C++ and SQL. That scale needs a good
namespace implementation to manage it!
As an example, I have an aspect "Directory" which contains Users, Computers,
Organization structure, etc for an organization. The Compliance Manager product
needs to extend these tables, in what is essentially a subclass relationship,
while using the base product's Directory features. The schema mapping of this
cross-aspect subclass relationship is affected by the fact that it's cross-aspect.
Absorption and partition are invalid mapping options. That's what I meant by
"conservative" mapping.
Clifford Heath.
Absolutely. There's a big difference between the core model and the xml file. The .orm files have a dummy root element (ormRoot:ORM2) that is a container for the 'real' information. The only special thing we do with this root element is provide an xml namespace mapping for all loaded domain models. Two of these are mapped automatically (ORMCore, ORMDiagram), the others are loaded as registered extensions. Although this is slightly non-standard from a pure XML perspective, where you can introduce namespaces at any node, there are a several advantages:
1) DSL domain models are loaded dynamically via .NET attributes, and the model cannot be extended after element population begins. Putting all of the namespace associations up front allows us to pull in the necessary models without walking the entire file.
2) The XML ends up much cleaner if you aren't constantly defining namespaces
Inside the root element we simply serialize all top-level elements from any loaded models. There is a natural hierarchy here (ORMDiagram references ORMCore, but not vice-versa). Top-level elements are determined by casting the domainmodel classes to IORMCustomSerializedDomainModel and asking for root elements (the implementation of the interface is generated. It is also likely to be renamed at some point and moved to the 'Framework' section given that there is nothing 'ORM' specific about it).
So, one option for adding additional information to the model file is to provide root elements in an extension domain model.
The other build in mechanism is through the extension framework. At the XML level, you'll see an orm:Extensions element with additional information relating to the ORM element. This allows model decoration without top-level extension and has some nice internal features (properties can mocked up on the fly for the Properties Window until you enter something other than the default settings).
A nice example of using extension properties is the 'Custom Properties' extension, which allows you to add typed properties to different parts of your model. Custom use both the Extensions element and root elements for serialization. [The property definition launch is hacked in right now, it appears as a checkbox on the Extension Manager dialog, but will be moved as an extension property on the model.]
The eventual goal here is associate extensions with different cross-cutting generators. All of our generation transforms spit transformable xml, which means that the generated 'code' itself is easily transformed, allowing the code to be modified without touching the primary transforms. We'll be adding support to our ORMCustomTool generation pipeline for cycling within a format (currently you progress between formats) to support this type of operation. I'd like to push this part of the project harder next quarter. The 'generator settings' (which generators you apply to the file) are separate from the extension data stored in the file. So, while we will add configuration settings to the generators to require certain extension elements, the choice of which generators to run against the model file will remain a project setting, not part of the model file.
Hopefully that gives a better understanding of what I mean by 'core model'. We are not locking anyone out of the main file in any way. In fact, we're trying to make the party as open as possible.
-Matt
PS I've hidden the IsExternal property until we do something real with it (in changeset 956)