mgd_get_me_by
Posted on 2005-03-02 14:09:37 EET.
I was wondering about get methods for Midgard (MgdObject) and GObject objects. If we can define get_by_id by defining id property of an object we can simply define any get method following object's properties which are set. This means that after you define object's property up and name you can simply get object exactly as current mgd_get_by_name(up, name). When up and title are set you can call object as mgd_get_by_title(up, title). This method doesn't exists , but do we need to write another method?. This is very simply kind of find() method. The real problem is that you never know if you can get fetchable or single object. get_by_id method always returns object or NULL, which is much more simple from any point of view.
Current methods for MgdObjects, update() or create() work very similiar as simply find() method should work.
We get class' properties, check if property is defined and generate query. PHP ( or Zend ) object's methods works
the same way , we "map" all not MgdObject properties to MgdObject's ones.
So how do I do it using midgard-php extension?
Well, it looks easy if you look at this code. update() or create() methods do not take care about ownership, sitegroup or any other access control layer at this moment.
It is almost impossible to define midgard *mgd or MgdSchema per class. The idea of current MgdSchema is that one schema may be shared between applications or virtualhost. So one class' connection or "parent" schema may ( and will ) be different. Current solution is to define object's schema and midgard structure when object is initialized. So new MgdObject is created like this:
Bad thing is that for every object created we need to look for type in schema. But if You consider how fast is midgard core and how slow may be midgard-php application you can agree that one call or querry speed is not important. Important is how fast is getting all data required by application.
SQL querry speed is another issue. We can make one big "join" like querry to get full object when its storage is defined
in more than one table. This is not as fast as one querry to get data from one table. But if you get data from one table
per querry you need to define as many queries as many tables object uses as storage. This means that midgard-php object properties stored in record_extension table can not be retrieved with another API functions. Exactly the same API must be used for replicated or serialized objects. This means that this API should be MgdObject's API. I was also wondering about the same usage for object's attachments. Following parameter's idea you could define blob's mimetype as domain , its name as name and blobs itself as value. Think about "getting" one field from table according to another two ones which may be groupped as array for object's property, assigned as another object or just like parameters.
Another problem with single queries is class inheritance. If MidgardArticle extends MidgardRepligardClass , how querry should be build when all parent class' properties are child's one? If MyMidgard extends MidgardArticle , how should we know which property is from parent class? Search parent class for property?
Lets's look at our update method and its sql querry.
Action field is not defined in article table so querry failed. It doesn't matter I did not specify such property with such field in my schema. Property is inherited from parent class. So again. Create two queries and find which class property belongs to? While schema is created it generates parts of sql and store it in MgdSchemaType structure which is assigned to object when this is initialized as its private property. One does not need to waste expensive CPU time to create select querry during get method. The same may be done for create or update methods ( if "may" :).
GParamSpec may be usefull here, as MgdSchema creates "table.field" entries as nick values when define default class members. So MidgardArticle name property has "name" property and "article_i.name" nick. This should also define ACL attributes , as Midgard objects requires more than read and write flags. Property like sitegroup can not be "write" or "read". A special case is required as such property should be updated or created only for SG0 administrator, and with particular ACL API.
When we define flags per property we should be able to control not only object itself , but also every single property.
You can try to use MgdSchema objects with latest CVS tarballs.
Using midgard-php extension you should be able to:
"Binary guys" responsible for binary packages of Midgard should start using latest CVS soon , as we slowly starting to prepare
1.7alpha release with changed core dependencies and midgard-data supporting fs midcom.
Current methods for MgdObjects, update() or create() work very similiar as simply find() method should work.
We get class' properties, check if property is defined and generate query. PHP ( or Zend ) object's methods works
the same way , we "map" all not MgdObject properties to MgdObject's ones.
So how do I do it using midgard-php extension?
<?phpor
$amerigard = new MidgardRocks();
$amerigard->get_by_id(1);
$amerigard->name = "Midgard is cool";
$amerigard->update();
?>
<?phpEasy?
$amerigard = new MidgardRocks();
$amerigard->name = "Midgard is cool";
$amerigard->create();
?>
Well, it looks easy if you look at this code. update() or create() methods do not take care about ownership, sitegroup or any other access control layer at this moment.
It is almost impossible to define midgard *mgd or MgdSchema per class. The idea of current MgdSchema is that one schema may be shared between applications or virtualhost. So one class' connection or "parent" schema may ( and will ) be different. Current solution is to define object's schema and midgard structure when object is initialized. So new MgdObject is created like this:
MgdObject *obj;
obj = midgard_object_new(midgard *mgd,
MgdSchema *schema,
gchar *name);
Bad thing is that for every object created we need to look for type in schema. But if You consider how fast is midgard core and how slow may be midgard-php application you can agree that one call or querry speed is not important. Important is how fast is getting all data required by application.
SQL querry speed is another issue. We can make one big "join" like querry to get full object when its storage is defined
in more than one table. This is not as fast as one querry to get data from one table. But if you get data from one table
per querry you need to define as many queries as many tables object uses as storage. This means that midgard-php object properties stored in record_extension table can not be retrieved with another API functions. Exactly the same API must be used for replicated or serialized objects. This means that this API should be MgdObject's API. I was also wondering about the same usage for object's attachments. Following parameter's idea you could define blob's mimetype as domain , its name as name and blobs itself as value. Think about "getting" one field from table according to another two ones which may be groupped as array for object's property, assigned as another object or just like parameters.
Another problem with single queries is class inheritance. If MidgardArticle extends MidgardRepligardClass , how querry should be build when all parent class' properties are child's one? If MyMidgard extends MidgardArticle , how should we know which property is from parent class? Search parent class for property?
Lets's look at our update method and its sql querry.
midgard-lib:1065:debug:query=UPDATE article SET up='0',locker='1',
approver='1',revisor='1',creator='1',type=136657063,locked='0000-00-00 00:00:00',
approved='0000-00-00 00:00:00',created='2003-04-28 05:56:46',revision=136656998,
revised='2003-04-30 09:46:00',score=136657126,name='index',extra3='',
extra2='',extra1='',print=136657020,view=136657009,icon=136657073,
caldays=136657114,calstart='1900-00-00',id=1,action='',
updated='',changed='',guid='',realm='' WHERE id=1 AND (sitegroup = 0 OR 0<>0)
midgard-lib:1065:debug:query failed: Unknown column 'action' in 'field list'
Action field is not defined in article table so querry failed. It doesn't matter I did not specify such property with such field in my schema. Property is inherited from parent class. So again. Create two queries and find which class property belongs to? While schema is created it generates parts of sql and store it in MgdSchemaType structure which is assigned to object when this is initialized as its private property. One does not need to waste expensive CPU time to create select querry during get method. The same may be done for create or update methods ( if "may" :).
GParamSpec may be usefull here, as MgdSchema creates "table.field" entries as nick values when define default class members. So MidgardArticle name property has "name" property and "article_i.name" nick. This should also define ACL attributes , as Midgard objects requires more than read and write flags. Property like sitegroup can not be "write" or "read". A special case is required as such property should be updated or created only for SG0 administrator, and with particular ACL API.
When we define flags per property we should be able to control not only object itself , but also every single property.
You can try to use MgdSchema objects with latest CVS tarballs.
Using midgard-php extension you should be able to:
- define class
- initialize object
- get object by id ( $object->get_by_id(int id) )
- create object ( $object->create() )
- update object ( $object->update() )
"Binary guys" responsible for binary packages of Midgard should start using latest CVS soon , as we slowly starting to prepare
1.7alpha release with changed core dependencies and midgard-data supporting fs midcom.