Helma Logo
main list history
previous version  overview  next version

Version 2 by hannes on 17. February 2009, 22:23

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
# object references
creator = object (user)
creator.local = TEXT_F_USER_CREATOR
creator.foreign = USER_ID
# primitive properties
title = TEXT_TITLE
text = TEXT_TEXT
createtime = TEXT_CREATETIME
modifytime = TEXT_MODIFYTIME
# 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> entry describes the database to use for storing objects of this type. <tt>dbname</tt> is the name of a database as defined in the <tt>db.properties</tt> file.

<pre>_db = dbname</pre>

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

<pre>_table = TABLENAME</pre>

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

<pre>_id = ID_COLUMN</pre>

The optional <tt>_name</tt> 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_COLUMN</pre>

The <tt>_parent</tt> 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> function.

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

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> entry. Simply specify the name of the parent type:

<pre>_extends = parenttype</pre>

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> entry, specifying a column in the table containing the name of the prototype for each row.

<pre>_prototype = PROTO_COLUMN</pre>

=== 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 = DB_COLUMN_1
prop2 = DB_COLUMN_2</pre>

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

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

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.private = true</pre>

=== 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 = object (protoype)
prop3.local = LOCAL_DB_COLUMN
prop3.foreign = FOREIGN_DB_COLUMN</pre>

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

=== 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>, 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>. The <tt>.foreign</tt> 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> value equals the <tt>LOCAL_DB_COLUMN</tt> value of the object holding the collection. Leaving away <tt>.local</tt> and <tt>.foreign</tt> creates a collection of all available objects of the specified prototype.

<pre>_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>

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

By default, child objects can be accessed from the containing parent object through their index-position or <tt>ID</tt> value. Additionally the entry <tt>.accessname</tt> 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.accessname = DB_COLUMN</pre>

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

<tt>filter</tt> 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> contains the sorting to be applied to the child objects. <tt>group</tt> tells Helma to group the objects in the collection according to the value in <tt>DB_GROUPCOLUMN</tt>.

<pre>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>
Notice the two appearences of <tt>order</tt> above. The first one, <tt>prop4.order</tt> sorts the objects, the second, <tt>prop4.group.order</tt> sorts the grouped objects, that Helma will create as a result of the <tt>group</tt> entry. With this it's also possible to sort the grouped objects ascending, but the contents of the grouped objects descending.

The <tt>prop4.group.prototype</tt> 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>. 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.
Table references can be aliased using <tt>TABLE_NAME AS ALIAS_NAME</tt> or <tt>TABLE_NAME ALIAS_NAME</tt>.

<pre>#Node is stored in in the database table NODE

#subChildren is a collection containing all the Node's children's children:
subChildren = collection(Node)
subChildren.filter.additionalTables = NODE AS CHILDREN

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 IN (ID_LIST)</tt> and <tt>FIND_IN_SET(ID_FIELD, ID_LIST)</tt>, <tt>ID_LIST</tt> 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.


#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})


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

=== 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.local.1 = FIRST_LOCAL_COLUMN
prop4.foreign.1 = FIRST_FOREIGN_COLUMN
prop4.local.2 = SECOND_LOCAL_COLUMN
prop4.foreign.2 = SECOND_FOREIGN_COLUMN</pre>

Whenever one specifies more than one restraint, the use of <tt>.[Number]</tt> 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>) to the URL string.

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

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

=== Advanced Settings

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

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

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

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

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