The ORM Foundation

Recently Jim Ludden asked how he could find orphaned object types (object types in the model, but not in any diagram). He was asking about NORMA, but I thought it would be interesting to try to solve the same problem for ORM Lite by writing a script. The following is one possible solution. My guess is that the script reads enough like English to be readily understandable. What do you think? Is there a part of the script that is puzzling or that you think might not work? 

------------

def PrintOrphans(project):
    objectTypesDisplayed = {} # all object types with graphics
    for diagram in project.GetList('Report'):  # look at all reports in project
        if diagram.ReportType.PanelType != 'ORMDiagram':
            continue  # ignore if not an ORM diagram
        for shape in diagram.GetGraphicList('ORMObjectTypeShape'):
            objectTypesDisplayed[shape.Target] = True  # object type in diagram

    notInDiagram = 0  # count object types not in any diagram
    allObjectTypes = project.GetList('ORMObjectType')
    for objectType in allObjectTypes:
        if objectType not in objectTypesDisplayed:
            print "Object Type '%s' is not in any diagram" % objectType.Name
            notInDiagram += 1
    print "%d of %d object types were not in any diagram" % (
            notInDiagram, len(allObjectTypes) )

def Do(reportWindow):
    rid = reportWindow.ReportID  # current report id
    report = Data.DBObject.GetObject('Report',rid)
    project = report.Project  # the project that contains the report
    PrintOrphans(project)

Do(self)  # 'self' refers to the current report window

------------

The ability to write scripts like this one is a major strength of ORM Lite.

Well I can just about figure out what it is doing but to be able to write such a script it seems to me that:

1: You would need to learn the language in which it is written.

2: You would need to know the "reserved words" in ORM Lite
For example  the statement:

rid = reportWindow.ReportID  # current report id

Seems to me to require a knowledge of the structure of ORM lite.
Is "rid" a variable name that you just invented?
Where does "reportWindow.ReportID" come from and to what does it refer?
What is the significance of adding " # current report id" on the end?

So it seems to me that whilst someone with curiosity, programming skills and a "developer" approach might see this as a "challenge", an "ordinary ORM user" would be completely lost.

Ken

Good comments. I certainly agree that writing scripts is a step beyond reading them. You quite rightly point out that to write scripts, it is necessary to learn the scripting language. Fortunately the scripting language comes with a very good tutorial ( http://docs.python.org/tutorial/ ). Many experienced programmers have said that they were able to pick up the essentials of the language in half a day. Non-programmers can take hope from the fact that many organizations have chosen this language to introduce programming to non-programmers, primarily because it is both very readable and relatively easy to learn. (A good example is the Natural Language Toolkit project. They have a web page that compares the readability of several languages. Not surprisingly our language wins. http://nltk.org/doc/en/app-nlp-python.html )

Your second point is also on target. To navigate the "reserved words" of the ORM Lite data model it would be vital to have a "road map". I'm working on that. My hope is that people who are familiar with ORM will have little difficulty learning the "street names and landmarks" of the object model. If it would be alright, I would like to publish a draft of the ORM Lite "road map" on this site to get some feed back from people here.

But let's not underestimate how useful it could be for an "ordinary ORM user" to be able to read the scripts that they are using. As tool users we often wonder what a command is actually doing, especially when the software doesn't behave as we would have expected. By reading the script we can get to the real story. At a minimum we see how simple or complex a particular command actually is and what data it is using.

On your specific questions:

Yes, "rid" is a name that I made up. I abbreviated "report id". 

"reportWindow" refers to the current report window that the user can see on the computer screen. This reference is available to scripts via the variable name "self". (This name appears in the line "Do(self)" which calls the procedure "Do" and passes it the contents of "self" as a parameter. The procedure "Do" takes the value that is passed and places it into a variable named "reportWindow".) Using the name "self" for the current window is a convention in ORM Lite to provide scripts with a starting point that they can use to look up information about the tool. Another example is "Data.DBObject". This is the starting point that scripts can use to find information in the model. The "ReportID" refers to an unique ID number that is assigned to each report when it is created. We can use the ID number to look up additional information in the report. In this case we want the report's project. In ORM Lite, a project corresponds to a schema. From the project, we can find the model objects and the other reports.

The additional of " # current report id" at the end of the line is documentation. In the scripting language, everything after a "#" character is ignored by the computer and is only for the person who is reading the script (unless the "#" is in quotes, then it is considered part of the character string to be processed by the script).

Whether an "ordinary ORM user" learns to write scripts probably depends on how great the motivation is to solve a particular problem and on the size of the road blocks that must be over come to do so. The road blocks we can do something about. Experience suggests that most users will probably never write scripts, but we can all benefit from those who do.