Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


Changing makeValidIdentifier

  • Clifford Heath
    Clifford Heath

    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

      • Clifford Heath
        Clifford Heath

        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

          • Clifford Heath
            Clifford Heath

            > 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.

            • Sten Sundblad
              Sten Sundblad

              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.


              • Clifford Heath
                Clifford Heath


                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.


              PS I've hidden the IsExternal property until we do something real with it (in changeset 956)