Helma Logo
main list history
previous version  overview  next version

Version 4 by hannes on 21. September 2009, 15:21

Helma 1 comes with its own home-grown Object-Relational Mapping framework.

=== ### Overview

Helma O/R maps rows from relational tables against JavaScript host objects called *HopObjects*. HopObjects are defined by prototype directories, which contain the JavaScript code and templates (called *skins* in Helma lingo) to be applied to them. The object-relational mapping itself is defined in a type.properties file, which may look like this:

    _db = antville
    _table = AV_TEXT
     
    _parent = site.stories
    _id = TEXT_ID
    _prototype = TEXT_PROTOTYPE
    
 _parent = site.stories  # object references
 _id   creator = TEXT_IDobject (user)
 _prototype   creator.local = TEXT_PROTOTYPETEXT_F_USER_CREATOR
    creator.foreign = USER_ID
 # object references    
 creator = object (user)  # primitive properties
 creator.local   title = TEXT_F_USER_CREATORTEXT_TITLE
 creator.foreign   text = USER_IDTEXT_TEXT
    createtime = TEXT_CREATETIME
    modifytime = TEXT_MODIFYTIME
    
    # primitive propertiescollections
 title   comments = TEXT_TITLEcollection (comment)
 text   comments.local = TEXT_TEXTTEXT_ID
 createtime   comments.foreign = TEXT_CREATETIMETEXT_F_TEXT_STORY
 modifytime   comments.filter = TEXT_MODIFYTIMETEXT_ISONLINE >
    comments.order = TEXT_MODIFYTIME DESC
# collections
comments = collection (comment)
comments.local = TEXT_ID
comments.foreign = TEXT_F_TEXT_STORY
comments.filter = TEXT_ISONLINE > 0
comments.order = TEXT_MODIFYTIME DESC

The different kinds of entries and their use are described below.

=== ### Basic Mappings

The <tt>_db</tt> `_db` entry describes the database to use for storing objects of this type. <tt>dbname</tt> `dbname` is the name of a database as defined in the <tt>db`db.properties</tt> properties` file.

<pre>_db     _db = dbname</pre>dbname

The <tt>_table</tt> `_table` entry tells Helma which table to use for objects of this type within the database.

<pre>_table     _table = TABLENAME</pre> TABLENAME

The <tt>_id</tt> `_id` entry defines the column to use as primary key. Helma requires a single primary key with no other functionality.

<pre>_id     _id = ID_COLUMN</pre>ID_COLUMN

The optional <tt>_name</tt> `_name` entry tells Helma which database column to use as object name. This is important for the user prototype, since it defines which column constitutes the user name.

<pre>_name     _name = NAME_COLUMN</pre>NAME_COLUMN

The <tt>_parent</tt> `_parent` entry contains a comma-separated list of properties of objects of this type to be used as parent. Objects must know their parent in order to generate correct URLs in their <tt>href()</tt> `href()` function.

<pre>_parent     _parent = property1, property2.collectionX, root.collectionY</pre>collectionY

If an entry in the _parent item does not contain a dot, it is interpreted as an object property of the current object that acts as the object's parent. If an entry contains a dot character, the part after the dot is interpreted as a collection in the parent object in which the current object is contained. If the _parent is specified as "root", it is not interpreted as a property of the current object. Instead, the application's root object is used as parent object.

A type can inherit its data mapping and functions from another type. This is done with the <tt>_extends</tt> `_extends` entry. Simply specify the name of the parent type:

<pre>_extends     _extends = parenttype</pre>parenttype

Extended prototypes are usually stored in the same relational database table. Thus, Helma needs a way to tell which row in the table should be instantiated with which object prototype. This is done using the <tt>_prototype</tt> `_prototype` entry, specifying a column in the table containing the name of the prototype for each row.

<pre>_prototype     _prototype = PROTO_COLUMN</pre>PROTO_COLUMN

=== ### Simple Property Mappings

The mappings for simple properties (versus properties that are objects containing further properties) simply map a property name of the specified object type to a column of the relational database table. The type of the property or column need not be specified. Helma does all necessary conversion when reading or writing a property value.

<pre>prop1     prop1 = DB_COLUMN_1
    prop2 = DB_COLUMN_2</pre>DB_COLUMN_2

To prevent a property from being overwritten by the application it can be made readonly.

<pre>prop1    prop1.readonly = true</pre>true

In a similar manner marking a property as private will prevent any corresponding collection or reference from being updated but still perform all necessary updates in the database.

<pre>prop1    prop1.private = true</pre>true

=== ### Object Reference Mappings

Properties that contain other objects are defined by the object keyword and the prototype name of the referenced object in brackets. The object reference is resolved via two entries:

<pre>prop3     prop3 = object (protoype)
    prop3.local = LOCAL_DB_COLUMN
    prop3.foreign = FOREIGN_DB_COLUMN</pre>FOREIGN_DB_COLUMN

<tt>prop3`prop3.local</tt> local` specifies the part of the reference in the local database-table, <tt>prop3`prop3.foreign</tt> foreign` the column in the table where objects of the referenced prototype are stored. By executing the assignment <tt>obj`obj.prop3 = someObject</tt>someObject`, the database-column specified by <tt>prop3`prop3.local</tt> local` will be set to the value of <tt>FOREIGN_DB_COLUMN</tt>`FOREIGN_DB_COLUMN`, or <tt>null</tt> `null` if <tt>someObject `someObject == null</tt>null`.

=== ### Collection Mappings

The following section describes the entries used to define collections of objects. There are two kinds of collections: First, every object can itself act as a collection, and second, it can define additional properties to be used as collections. Direct descendents are defined with entries starting with <tt>_children</tt>`_children`, while additional collections are defined using their property name. Otherwise the syntax for the two is the same.

The following are examples for simple collection mappings for both the direct descendants and those contained in a collection-property called <tt>prop4</tt>`prop4`. The <tt>`.foreign</tt> foreign` entry is used in both cases to specify a column in the foreign table used to collect the objects. Exactly those objects will be collected whose <tt>FOREIGN_DB_COLUMN</tt> `FOREIGN_DB_COLUMN` value equals the <tt>LOCAL_DB_COLUMN</tt> `LOCAL_DB_COLUMN` value of the object holding the collection. Leaving away <tt>`.local</tt> local` and <tt>`.foreign</tt> foreign` creates a collection of all available objects of the specified prototype.

<pre>_children     _children = collection (protoype)
    _children.local = LOCAL_DB_COLUMN
    _children.foreign = FOREIGN_DB_COLUMN

    prop4 = collection (protoype)
    prop4.local = LOCAL_DB_COLUMN
    prop4.foreign = FOREIGN_DB_COLUMN</pre>FOREIGN_DB_COLUMN

By executing <tt>obj`obj.add(otherObj)</tt> add(otherObj)` resp. <tt>obj`obj.prop4.add(otherObj)</tt>add(otherObj)`, the <tt>FOREIGN_DB_COLUMN</tt> `FOREIGN_DB_COLUMN` will be set to the value of <tt>LOCAL_DB_COLUMN</tt>`LOCAL_DB_COLUMN`.

By default, child objects can be accessed from the containing parent object through their index-position or <tt>ID</tt> `ID` value. Additionally the entry <tt>`.accessname</tt> accessname` can be used to specify a database column in the child table. The value of this column will be used as name of the objects contained in this collection.

<pre>prop4    prop4.accessname = DB_COLUMN</pre>DB_COLUMN

With the above mapping, an object contained in the <tt>prop4</tt> `prop4` collection with a <tt>DB_COLUMN</tt> `DB_COLUMN` value of "xyz" would be reachable as <tt>this`this.prop4.xyz</tt> xyz` from the containing object.

<tt>filter</tt> `filter` can be used to add an additional condition for the selection of objects which is not dependent on the object holding the collection. <tt>order</tt> `order` contains the sorting to be applied to the child objects. <tt>group</tt> `group` tells Helma to group the objects in the collection according to the value in <tt>DB_GROUPCOLUMN</tt>`DB_GROUPCOLUMN`.

<pre>prop4    prop4.filter = DB_FILTERCOLUMN is not null
    prop4.order = DB_ORDERCOLUMN desc
    prop4.group = DB_GROUPCOLUMN
    prop4.group.order = DB_GROUPORDERCOLUMN
    prop4.group.prototype = SomePrototype</pre>SomePrototype
 
Notice the two appearences of <tt>order</tt> `order` above. The first one, <tt>prop4`prop4.order</tt> order` sorts the objects, the second, <tt>prop4`prop4.group.order</tt> order` sorts the grouped objects, that Helma will create as a result of the <tt>group</tt> `group` entry. With this it's also possible to sort the grouped objects ascending, but the contents of the grouped objects descending.

The <tt>prop4`prop4.group.prototype</tt> prototype` property sets the Prototype to be used for the group objects generated by Helma.

Filters can contain references to the values of the current object's database entry fields. This is the syntax for these variables: <tt>${FIELD_NAME}</tt>`${FIELD_NAME}`. The variables are then replaced by the actual values of the fields before the query is executed.
With these variables, the above collection could also be described like this:
<pre>prop4 = collection (protoype)
prop4.filter = FOREIGN_DB_COLUMN = ${LOCAL_DB_COLUMN}</pre>

<tt>filter.additionalTables</tt> allows adding additional tables to the query, so that their fields can be used in the condition of the filter as well. The table of the collection's prototype is allways the first table in the query.  prop4 = collection (protoype)
Table references can be aliased using <tt>TABLE_NAME AS ALIAS_NAME</tt> or <tt>TABLE_NAME ALIAS_NAME</tt>    prop4.filter = FOREIGN_DB_COLUMN = ${LOCAL_DB_COLUMN}

<pre>#Node is stored `filter.additionalTables` allows adding additional tables to the query, so that their fields can be used in in the database condition of the filter as well. The table NODEof the collection's prototype is allways the first table in the query. Table references can be aliased using `TABLE_NAME AS ALIAS_NAME` or `TABLE_NAME ALIAS_NAME`.

#subChildren     #Node is a collection containing all stored in in the Node's children's children:database table NODE
subChildren = collection(Node)  #subChildren is a collection containing all the Node's children's children:
subChildren.filter.additionalTables     subChildren = NODE AS CHILDRENcollection(Node)
    subChildren.filter = NODEfilter.FOREIGN_DB_COLUMN additionalTables = ${LOCAL_DB_COLUMN} AND NODE.LOCAL_DB_COLUMN = NODE AS CHILDREN.FOREIGN_DB_COLUMN
</pre>    subChildren.filter = NODE.FOREIGN_DB_COLUMN = ${LOCAL_DB_COLUMN} AND NODE.LOCAL_DB_COLUMN = CHILDREN.FOREIGN_DB_COLUMN

Another example: Short arrays of objects of which the sequence can be changed without using a position field for each object can be created with the SQL statements <tt>ID_FIELD `ID_FIELD IN (ID_LIST)</tt> (ID_LIST)` and <tt>FIND_IN_SET(ID_FIELD`FIND_IN_SET(ID_FIELD, ID_LIST)</tt>ID_LIST)`, <tt>ID_LIST</tt> `ID_LIST` being a string field that contains the IDs seperated by commas. This comes in handy when the objects are used in more than one such array and the objects stored in such a way should know about all their referencing objects.

<pre>#Object1/type**Object1/type.propertiesproperties**:

    #the id list string containing a comma seperated list of OBJECT2 ids:
    strObject2Ids = OBJECT2_IDS

    #object2s lists the Object2 objects as referenced by strObject2Ids:
    object2s = collection(Object2)
    object2s.filter = OBJECT2.ID IN (${OBJECT1.OBJECT2_IDS})

#Object2/type**Object2/type.propertiesproperties**:

    #object1s lista all Object1 objects that are referencing this Object2 through their object2s collection:
    object1s = collection(Object1)
    object1s.filter.additionalTables = OBJECT2
    object1s.filter = OBJECT2.ID = ${ID} AND FIND_IN_SET(OBJECT2.ID, OBJECT1.OBJECT2_IDS)</pre>OBJECT2_IDS)

=== ### Additional Join Conditions

For both object and collection mappings, it is possible to provide any number of additional restraints used to join the local with the other table to further limit the selected objects.

<pre>prop4    prop4.local.1 = FIRST_LOCAL_COLUMN
    prop4.foreign.1 = FIRST_FOREIGN_COLUMN
    prop4.local.2 = SECOND_LOCAL_COLUMN
    prop4.foreign.2 = SECOND_FOREIGN_COLUMN</pre>SECOND_FOREIGN_COLUMN

Whenever one specifies more than one restraint, the use of <tt>.[Number]</tt> number suffix is mandatory.

=== ### Mountpoint Mappings

Mountpoints provide a simple way to directly attach a prototype to the URL path. If the path contains the name of a mountpoint the prototype's objects are accessible simply by adding their id (or a property defined by <tt>`._accessname</tt>) _accessname`) to the URL string.

<pre>myMountpoint     myMountpoint = mountpoint(myProto)</pre>mountpoint(myProto)

In the example above, the path <tt>/myMountpoint/23/test</tt> `/myMountpoint/23/test` refers to the action <tt>test`test.hac</tt> hac` of the object with id 23, which is derived from the <tt>myProto</tt> `myProto` prototype.

=== ### Advanced Settings

Some techniques to optimize Helma's strategy for managing objects from a relational table.

<dl><dt><b>_children.loadmode=aggressive</b></dt>
<dd>When this is set for _children or a virtual node, all child objects will be fetched in one query. The default way is to just fetch an index of children consisting of the object's keys, and then fetch the objects on demand, which allows the Hop to scale to large child collections where only few of the objects are actually accessed.</dd>

<p>
<dt><b>_children.cachemode=aggressive</b></dt>
<dd>By default, Hop refreshes a children index when any object with the prototype contained in the subnodes was modified since the last access. By setting this flag on _children or a virtual node, children will only be refreshed when an object is added to or removed from the child collection itself, or an object already contained in it is modified.</dd>

<p>
<dt><b>_children.maxsize=XX</b></dt>
<dd>
When specifying children (either directly or within a virtual container) an optional maxsize property can be used to limit the number of objects contained. A setting of e.g. 100 would cause the collection to contain maximally 100 objects, regardless of how many (matching) rows the database table contains.
</dd>


<p>
<dt><b>propname.readonly=true</b></dt>
<dd>Use the readonly flag to tell the Hop never to update this column in the database. Actually the column won't be updated if the property is not modified, but this is like an extra layer of security.</dd>

<p>
<dt><b>propname.private=true</b></dt>
<dd>The readonly flag tells Hop to update this column in the database only, but to prevent any collections containing or any other object referring to the very object with that property.</dd>
</dl>

     removed
     added