Feedback on current O/R Mapping Unittests

[Ren]

Yes, but NULL isn't the type expected no? Say... I must be thick this morning

function __construct(B $b = null)

$b has to be of type B or null. the = null allows nulls to be passed in. Whereas function __construct(B $b) requires a object of type B.

[sweatje]

Yes, but NULL isn't the type expected no? Say... I must be thick this morning

No thicker than usual. It was added recently to PHP (5.1.2 IIRC) to allow for option typed parameters. The only allowed value for a default typed parameter is NULL.

[thr]

Could we stop the Off Topic now ?

Off Topic:

Ok some more ot, I've always wondered what the "IIRC" abbrv stands for ;p, anyone?

[thr]

Ren, how about this then:

    protected function PersonMap(){
        $map = new ClassMap;
        $map->name        = Model::string(25);
        $map->email        = Model::string(50, true); // allows null
        $map->age        = Model::integer(3);
        $map->text        = Model::text("long");
        $map->groups    = Model::collection("Group");
        $map->children    = Model::collection("Person");
        $map->parent    = Model::object("Person");
        
        $map->naturalKey("name","email"); // sql: unique(name, email)
        return $map;
    } 

[Ren]

Yeah, they could be statics I suppose.

And...

IIRC = If I Remember Correctly

[Dr Livingston]

> No thicker than usual.

No need to get personal about it okay? That wasn't called for actually

> It was added recently to PHP (5.1.2 IIRC) to allow for option typed parameters.

Well I'm using 5.1.1 at the moment, but I can't say that I knew of the change anyways.

[Ren]

Ah, according to this, http://derickrethans.nl/typehints_and_null.php , its in 5.1.0.

[sweatje]

Off Topic:

> No thicker than usual.

No need to get personal about it okay? That wasn't called for actually

It was not meant to be personal, only that the change was recent and you might not have been aware of it, and therefore not you did not have to be particularly "thick" as you stated.

My apologies for leaving it ambiguous.

[thr]

Ok, more ideas comming up - after the insane amount of ORM threads here on sitepoint, this is my current idea(it would only allow one DB connection at a time to be active, I could do some type of selfcontained static registry for the model to allow more - but for now this will suffice), there would be some static abuse(Model + UoW + IDMap = static) to get a better "feel" to it and being able to create mappers / domain objects as you wish.

The use would look something like this:

Model::paths('./Classes/', './Internal/');
Model::connect('mysql', 'localhost', 'development', 'dev', 'devnull');

$mapper                = new PersonMapper;
$persons            = $mapper->find(1);

$person            = new Person;
$person->surname    = "John";
$person->familyname    = "Doe";

Model::commit(); 

And the mapping in the PersonMapper (in this case) something like:

class PersonMapper extends ModelMapper{
    
    public function __construct(){
        $this->setTable("Persons");
        $this->hasMany("Post.author");
        $this->hasOne("Presentation.owner");
        $this->belongsTo("Person.id", "parent");
        $this->hasInternal('Money', array('savings', 'currency'));
        parent::__construct();
    }
    
} 

If you don't want any special functionallity there's no need to create the "Person" class as it will be created automaticly at runtime for you - if you wan't other stuff in there go ahead and create your own, etc.

[thr]

I've decided not to go with the static approach as it's way to limiting in terms of database connectivity, etc. Going to post some new design ideas later on.

[Ren]

I've decided not to go with the static approach as it's way to limiting in terms of database connectivity, etc.

Good

[thr]

Ok, now we're talking something like this(Yes I think I'm going to adopt the Zend_Framework _-style as I feel it's a decent workaround do the current php namespace/package problems):

<?php
class PersonMapper extends Model_Mapper{

     protected function mapping(){
         #Model_Mapper::bind($sqlfield, $objectfield = null, $type = null, $key = false)
          $this->bind("person_id", "id", "integer", true);
          $this->bind("name");
          $this->bind("savings", null, "float");
          $this->bind("currency");
          $this->bind("parent", null, "integer");
         #Model_Mapper::hasMany/HasOne($locator, $name = null);
         #if $name is not specified it'll take the left most part of the locator
          $this->hasMany("Post.author");
          $this->hasOne("Presentation.owner");
         #Model_Mapper::belongsTo($locator, $name)
         #$name is required for belongsTo as it must be a bound field
          $this->belongsTo("Parent.id", "parent");
         #Model_Mapper::internal($type, $fields, $name = null);
         #if $name is not specified it'll use the first element in $fields
         $this->internal("Money", array("savings","currency"));
         $this->class("Person");
         $this->table("Persons");
     }

}
?>

It's either this(If I can get it to work and many people feel it's a nice approach) or I'm going with a table data gateway ;p. This is by far the most "clean" approach I've come up with as I wan't to have fieldbinding so you can select what fields to use and what name they should have on the object.

Edit:

Model_Mapper::internal() should maybe be named embedded() instead, can't realy decide on a nameing for it

[akrabat]

Looks reasonable to me as the amount of code required for a simple table is pretty small, yet you can get as complex as you need.

[thr]

I wast thinking about adding a Model_Mapper::use(str field [, str field [, ...] ]) method that would allow you to do this: $this->use("name","currency","age"); which would basicly be a shortcut to calling $this->bind("name"); $this->bind("currency"); and $this->bind("age"); if you just want to use them under thier table name without any typecasting.

[akrabat]

That's not a bad idea either.

[Ren]

Ok, now we're talking something like this(Yes I think I'm going to adopt the Zend_Framework _-style as I feel it's a decent workaround do the current php namespace/package problems):

<?php
class PersonMapper extends Model_Mapper{

     protected function mapping(){
         #Model_Mapper::bind($sqlfield, $objectfield = null, $type = null, $key = false)
          $this->bind("person_id", "id", "integer", true);
          $this->bind("name");
          $this->bind("savings", null, "float");
          $this->bind("currency");
          $this->bind("parent", null, "integer");
         #Model_Mapper::hasMany/HasOne($locator, $name = null);
         #if $name is not specified it'll take the left most part of the locator
          $this->hasMany("Post.author");
          $this->hasOne("Presentation.owner");
         #Model_Mapper::belongsTo($locator, $name)
         #$name is required for belongsTo as it must be a bound field
          $this->belongsTo("Parent.id", "parent");
         #Model_Mapper::internal($type, $fields, $name = null);
         #if $name is not specified it'll use the first element in $fields
         $this->internal("Money", array("savings","currency"));
         $this->class("Person");
         $this->table("Persons");
     }

}
?>

It's either this(If I can get it to work and many people feel it's a nice approach) or I'm going with a table data gateway ;p. This is by far the most "clean" approach I've come up with as I wan't to have fieldbinding so you can select what fields to use and what name they should have on the object.

Edit:

Model_Mapper::internal() should maybe be named embedded() instead, can't realy decide on a nameing for it

Looks fine, looks like you've chosen to single column PKs, in the in both the bind() and has*()?

[Ren]

Also just had a thought (whilst experimenting with defining relations with MadCap) do you really need both hasOne() and hasMany() ?

Should be able to deduce that by the checking the wether the joining field is a PK or FK.

PS

$this->hasOne($catalog->Titles, $catalog->Titles->id == $this->titleId);

Quite neat I think..

[Dr Livingston]

Maybe you could have...

public function getQuantity() { ... }
// instead? 

[thr]

Looks fine, looks like you've chosen to single column PKs, in the in both the bind() and has*()?

You can bind multiple keys, such as(for a membership class):

$this->bind("person",null, "integer", true);
$this->bind("group",null, "integer", true);

And about the has*(), it seems rather awkward to handle relations with multiple keys?

Maybe you could have...

public function getQuantity() { ... }
// instead? 

Hmm.. I'm not following you here... ;P

Also just had a thought (whilst experimenting with defining relations with MadCap) do you really need both hasOne() and hasMany() ?

Should be able to deduce that by the checking the wether the joining field is a PK or FK

Ok, that's one good idea - I'll look into it.

[Ren]

Also wondering that should be able to only define relationships once.. if two tables are related would have to define the same relationship twice.

[mwmitchell]

Can't seem to load the model.serverside.se website. Anyone know if this is still being worked on?

- matt