Some MgdSchema notes
Here are quick notes from today's MgdSchema discussions with Piotras.
- The idea is to define Midgard objects in XML the same way as Repligard does
- Current status of MgdSchema is an app that parses the schema and displays it as debug info
- The object definitions will be reloaded every time Midgard is started
- MgdSchema will provide the object types as GObjects
- The GObjects are stored using the Gnome-DB abstraction layer
- When mgd_get_article() is called, the PHP binding will get the GObject from Midgard core instead of making its own queries
On the database backend, the object would be split to three or five tables. GUIDs will be used for linking same record between tables:
schema's own table (based on the XML file, same name as schema) with all the properties from the schema.
| guid | title | content |
|---|---|---|
| abc | Cool news | Blah blah blah... |
metadata table with Midgard ownership and metadata info:
| guid | creator | revisor | ... |
|---|
membership table for tree structures and ownerships:
| guid | parent | extra |
|---|
record_extension table (parameter API)
| guid | domain | name | value |
|---|
localization table (for MultiLangable fields)
| guid | language | property | value |
|---|
The way forward:
- Schema loading/parsing
- GObjectization of the schema
- Object persistence through Gnome-DB
- Query API (query and fetch)
- Storage API (create and update)
- PHP5 bindings for the object
- Object serialization
- Repligard-like tool based on MgdSchema
- More complete database handling
- Modification of database tables based on loaded schemas
- Complete "Classic Midgard" schemas
- 1.x compatibility API written in PHP (Midgard Lite like)
Updated 17:27: Since the gathering has been mostly on agenda, and my talking points are mostly handled, we can focus the main thing of any Midgard event:
