mRFC 0012: MgdSchema

The main aim of creating MgdSchema is to stadardize way of creating Midgard objects, way of managing objects and what is most important way of keeping all Midgard objects and databases records in the same uniform manner. Midgard became popular ( almost real application server ) due to midgard-php4 extension which allowed many php developers to develope new applications using this extension and only this extension making the same applications inconsistence.

Convention of this mRFC

Any *object* used in this mRFC doesn't describe real object in OOP meaning. It describes only types or database records which may be used as real objects in any application which uses OOP. This mRFC doesn't also focus on PHP OOP programming. Any OOP examples used in this mRFC uses PHP language as midgard-php is going to be the first midgard "extension" which should follow MgdSchema rules.

Data storage

MgdSchema is a special structure which is directly available only in midgard-core (the library) using C language. MgdSchema itself uses GHash tables and GObjects and depends on glib libraries, and therefore never should be created with other languages like C++ or Java. MgdSchema is a special handler for all defined midgard datatypes (objects) and describes how many and what types are used in midgard-core. Midgard library API ( and only library ) is responsible for Midgard internal logic. Midgard extensions written in other languages (Ruby, PHP, Java, C++) should always use Midgard library API and use the same MgdSchema independent from used language.

Define objects and database records relations.

The only way of defining Midgard types is to define them in xml format file.

Schema file has only two mandatory element names: "type" and "property", which describe type which should be registered and its property or properties. Such minimal definition creates new types which can not be stored in any database type.

Additionaly every element may have optional attributes.

Type definition:

Attributes:

name describes name of type which should be registered

table points to table name which stores objects data

parentfield points to field which stores value for tree's parent object id

parent points to type's name which is parent type in midgard tree

type name="NewMidgardArticle" table="article" parent="NewMidgardTopic"

Property definition:

Attributes:

name describes property name which should be used for objects

optional:

type defines the type of property

available types:

• string ( default )
• integer
• longtext
• float
• bool
• datetime

primaryfield points to table's field which store object's identifier ( id or guid )

upfield points to table's field with "up" object's identifier ( id or guid )

parentfield points to table's field with "parent" object's identifier ( id or guid )

multilang defines whether object should use multilang content ( this attribute has no particular value ) and must be used ( at least once ) together with table attribute

table describes what table should be used for property

field points to field which stores value for this property

 property name="url" table="article_i" field="my_url"

property name="topic" type="integer" parentfield="topic"

One special exception which can not be never defined in xml file is MgdObject which is core Midgard object describing metadata of Midgard types. MgdObject is the only one Midgard type which should be always hardcoded in midgard-core sources. Any "property" which is a member of MgdObject should be always ignored by midgard xml parser and never used as any other type's property. The best example is sitegroup property.

MgdObject definition

As MgdObject is the real one Midgard object, must describe object's metadata properties.

* guid
* owner
* parent
* created
* creator
* revised
* revisor
* updated
* approved
* approver
* locked
* locker
* author

Any other types (objects) should extend MgdObject and provide the same way of defining data. Thinking about midgard-php such solution allows approve objects like topic or even attachment.

MgdSchema benefits

Methods used for objects in any OOP language may be stndardized and defined not for objects itself but for extension. For example midgard-php could use such methods:

$object->is_owner();

$object->is_member();

$object->is_in_tree();

$object->is_parent();

$object->is_type();