|
New Format for Object-Relational Mapping (Version 2) The new format for describing the mapping of HopObject prototypes to relational database tables. Implemented. This proposal defines a new way to map objects in a Helma application to relational database tables. It uses a similar property file format as is currently used. This is because I think that the problematic aspect of the current solution is not the file format, but the terms in which type structure is described. The aim of this proposal is to remove some of the more bizarre expressions, use a terminology that is closer to the relational database model it describes, and be as coherent as possible, using the same or similar constructs for similar tasks.
The format described in this document contains two kinds of entries: Those entries which define meta- or internal information about the mapping, and those entries which define the actual properties of objects and how they are mapped to the database. To be able to distinguish between those two kinds of entries and to avoid name collisions, the former start with an underscore character ("_"). The _version entry allows Helma to support both the old and the new format while the new format is being implemented. Later on, support for the old format may be dropped. The allowed values are "1.0" and "1.2". The default value will switch from 1.0 to 1.2 as soon as the implementation is finalized.
The _db entry describes the database to use for storing objects of this type. dbname is the name of a database as defined in the db.properties file.
The _table entry tells Helma which table to use for objects of this type within the database.
The _id entry defines the column to use as primary key. Helma requires a single primary key with no other functionality.
The optional _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.
The _parent entry contains a 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 href() function.
Every object in a Helma application can act as a container for other objects. The description of what objects are child objects and how they're reachable is one of the more complex tasks when composing a relational type mapping. The available options are described fully in the last section.
Simple property mappings The mappings for simple (non-object) properties simple 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.
Object property 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:
prop3.local specifies the part of the reference in the local database-table, prop3.foreign the column in the table where objects of the referenced prototype are stored. By executing the assignment obj.prop3 = someObject, the database-column specified by prop3.local will be set to the value of FOREIGN_DB_COLUMN, or null if someObject is 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 _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 prop4. The .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 FOREIGN_DB_COLUMN value equals the LOCAL_DB_COLUMN-value of the object holding the collection. Leaving away .local and .foreign creates a collection of all available objects of the specified prototype.
By executing obj.add (otherObj) resp. obj.prop4.add (otherObj), the FOREIGN_DB_COLUMN will be set to the value of LOCAL_DB_COLUMN. By default, child objects can be accessed from the containing parent object through their index-position or ID-value. Additionally the entry .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.
With the above mapping, an object contained in the prop4 collection with a DB_COLUMN value of "xyz" would be reachable as this.prop4.xyz from the containing object. The filter and order entries remain unchanged from the current implementation. filter can be used to add an additional condition for the selection of objects which is not dependent on the object holding the collection. order contains the sorting to be applied to the child objects. groupby, as it is called in the current implementation, is renamed to group. This entry tells Helma to group the objects in the collection according to the value in DB_GROUPCOLUMN.
Notice the two appearences of order above. The first one, prop4.order sorts the objects, the second, prop4.group.order sorts the group-objects, that Helma will create as a result of the group entry. With this it's also possible to sort the group-objects ascending, but the contents of the group-objects descending. Specifying 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.
Whenever one specifies more than one restraint, the use of .[Number] is mandatory.
... comment
hns,
Friday, 17. August 2001, 11:09
Added _version entry
This allows us to support both formats for the time being, and to switch between the two on a per-prototype basis.
... link ... comment
tobi,
Friday, 17. August 2001, 11:43
local / foreign database table
could anybody please explain the meaning of local database table and foreign database table?
... link ... comment
hns,
Friday, 17. August 2001, 12:09
Local and foreign tables
When you define an object reference or a collection, you specify a relation between an object of the prototype whose type mapping you're editing and one or more objects of another prototype. The local table is the table of the current prototype, and the foreign table is the table of the other prototype. So the "local" entry specifies the column in the local table which is used for the relation while the "foreign" entry specifies the one in the foreign table. (Of course these tables may be one and the same, if you're actually defining a relation from one prototype to itself.)
... link ... comment
grob,
Friday, 17. August 2001, 18:57
_version
is a really great idea!
... link ... comment
chris,
Sunday, 19. August 2001, 19:17
what about _revision?
Probably a prototype revision element would be useful, too - so one could easily (plus ou moins ;-) find 'old' objects. It should be possible to access the prototype revision via hopobject.__revision__.
... link ... comment
hns,
Monday, 20. August 2001, 10:37
Interesting idea
but it would only be useful for objects stored in the embedded database. With a relational database, if you do a schema update, you usually restart the application and all objects are automatically up to jour.
... link ... comment
michi,
Monday, 27. August 2001, 12:48
while talking about [mountpoints]
how do they fit into the new schema?
keep the square brackets or rename it to sthg. including "module", since this is the purpose of that feature? ... link ... comment
stefanp,
Monday, 15. October 2001, 18:31
readonly-mode
_readonly=true
i'd like to be able to set a whole prototype to readonly mode (which is currently only possible for a single property). could be useful if you're working and testing with a delicate foreign database. ... link ... comment
stefanp,
Tuesday, 24. September 2002, 15:07
Re: New Format for Object-Relational Mapping (Version 2)
missing:
- mark as private (won't trigger a reload of children-arrays) - _idgen for oracle - mountpoint -readonly ... link ... comment
stefanp,
Friday, 29. November 2002, 17:28
Re: New Format for Object-Relational Mapping (Version 2)
wondering about the _parent setting: "The available options are described fully in the last section." section seems to be missing ...
... link ... comment |
navigation
Download
Community
Weblog
Mailing Lists
IRC Channel
Documentation
Introductions
Tools
Reference
Project
Roadmap
Bug Reporting
Source
Wiki
Tags
Updates
Related Projects
search
|
|||||||||||||||||