@Pieter,
What hold you to eagerly-load all related resource, instead doing another check within your extension? (thats what ‘relate’ method about, right?) Iam interested, if some of you, need something which not provided by internal method within this ORM (because possibly, i could include those additional functionality in new version, if i could see potential benefits of having it).
About your proposal in the many-to-many naming convention, i am still not seeing the significant benefits to adding more logic within relationship hydrator.
In new version, you would define model relationship as follow : (eg, we use the classic example of user <-> wife)
user model will be something like :
<?php namespace Model;
use \Gas\Core;
use \Gas\ORM;
class User extends ORM {
function _init()
{
// Define relationships
self::$relationships = array(
'wife' => ORM::has_one('\\Model\\Wife', NULL, array('select:id,name')),
);
// Define fields definition
self::$fields = array(
'id' => ORM::field('auto[3]'),
'name' => ORM::field('char[40]'),
'email' => ORM::field('email[40]'),
'username' => ORM::field('char[10]', array('required', 'callback_username_check')),
);
}
}
Then wife model will be something like :
<?php namespace Model;
use \Gas\Core;
use \Gas\ORM;
class Wife extends ORM {
function _init()
{
// Define relationships
self::$relationships = array(
'user' => ORM::belongs_to('\\Model\\User'),
);
// Define fields definition
self::$fields = array(
'id' => ORM::field('auto[3]'),
'user_id' => ORM::field('int[3]'),
'name' => ORM::field('char[40]'),
'hair_color' => ORM::field('email[20]'),
);
}
}
Furthermore, if you look closer for those new way of how this ORM define its relationship between entities(look at the develop branch, in unit testing section, for complete usage tests), there are 4 new things already :
1. Relationship aliasing :
Mean you could name your relationship entity with something else (this will handy for long-named of table(s)).
2. Tier models configuration, still with custom key(for custom relationship which could not follow convention). So in many to many, we could have something like :
self::$relationships = array(
'job' => ORM::has_many('\\Model\\Job_user => \\Model\\Job', 'custom_key', array('select:id,name'),
);
// '\\Model\\Job_user => \\Model\\Job' above represent the flow to reach the relationship entity
// so ORM first will take intermediate records from the first tier (Model\Job_user) then next tier(Model\Job)
// This way, it will possible to set up a relationship between several tiers of entity.
Which i think will resolve your many-to-many proposal above (and actually, also remove the necessary of ‘through’ option). The reason why is really simple : to avoid stacking “i-will-guess-for-you” logic within this ORM, and let developer choose how and what they want to do with his each entities.
3. Pre-process query for relationship. So you could tell how your relationship entity would fetched by adding more SQL clause. This can be done both in _init method or/and when we try to reach those relationship method (on the fly).
4. Regarding how we reach related entity. In this case (user <-> wife) instead the old syntax, which posibly something like :
$user1 = Gas::factory('user')->find(1);
$user1_wife = $user1->wife;
We will have something like
$user1 = Model\User::find(1);
$user1_wife = $user1->wife();
// or if we try to pre-process the wife entity,
// let say we only want to fetch the id and name:
$user1_wife = $user->wife('select:id,name');
So seriously, did we need more, after this changes? 😉