[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition)

[eluser]OverZealous[/eluser]
Whew, lotta stuff :-)

[quote author="ntheorist" date="1248493769"]I've been using a join_key() method i wrote up a while ago but what i really want to do is integrate 'extending' tables, which would be pretty much self joins but enforced automatically (like classes) – so say you had a 'person' model and you wanted a 'user' model to extend it (rather than being a separate relation on its own). It would be similar to the original self-joins (ie class User extends Person), but would automatically include the fields. I can see working it into DMZ using set_join_field perhaps?[/quote]

I'm not 100% sure what you are asking here. Currently, you can create more than one Model off the same table. There's nothing in the docs on that, but I haven't figured I needed to yet. I did it like this, though:

Code:

class Person extends DataMapper {
    $table = 'people';
    $model = 'person';

    $has_one = array('company');
}

class User extends Person {
    $table = 'people';
    $model = 'user';
    $has_one = array(
        'company' => array(
            'join_self_as' => 'person'
        )
    );
}

class Company extends DataMapper {
    $has_one = array(
        'person',
        'user' => array(
            'join_other_as' => 'person'
        )
    );
}

I don't like doing this, but I have a lot invested in existing code that looks similar to the above (different models). In hindsight, I should have just added an "is_user" flag to Person. It would be much easier to maintain! You could still handle simple joins like this:

Code:

class Widget extends DataMapper {
    $has_one = array(
        'user' => array(
            'class' => 'person'
        )
    );
}

$widget->user->get();

heh i can pick out parts of the original in there – y'know i wonder if stensi still cruises the forums and knows how far his original project had been taken?

I used the original DM docs as a starting point. Stensi knows, as I have contacted him. I was hoping (originally) to not have a completely separate fork, but he has been really busy. I don't know what to expect when/if he comes back. DMZ has made some major changes now, and "merging" them might be difficult. 8-/

one quick question i had (looking at the code) - is how does DMZ process queries with joined relations?

DMZ will automatically join related information if told to, but only then. You should check out include_related under the Get (Advanced) section.

btw i gotta say i really like how you laid out the development src.

Thanks. It's necessary, because my IDE was starting to give me fits. It's a huge file. Personally, if I could start over, I would have separated out all the validation rules, and probably broken the class into multiple classes that inherited each other, like CodeIgniter's DataBase classes. But that isn't practical, since it would require a significant effort, and provide minimal performance benefit, or even reduce performance.

Also I attempted to move the validation into a separate library

I have no plans to modify the way validation works as of now. It's pretty good, anyway, as it only loads the CI Form_Validation library when it is accessed, so it shouldn't load it if you never use rules from Form_Validation. Check out __get (in 15_magic.php) to see how it is done.

[eluser]ntheorist[/eluser]
hrm, what i mean with extending tables automating the joining of the extending model to the base model without having to specify relationships.

So say the person table would have the columns

id, firstname, lastname, phone, email

and a User

id, person_id, username, password, lastlogin, salt, (inherits firstname, lastname, phone, email from person)

This wouldn't be meant to be a standard 'parent' relationship. whenever you call a new User(), it would automatically join the users table to the people table, and act as if they were one. Users would have extra fields but would always inherit from the people table, as well as its methods and such, sort of reflecting OO extends, methods, overrides etc. There'd be some tricky things with this, how to merge validation for instance, or inherit relationships.. but does it make sense? You could take it further and have a table 'admins' which extends users which extends people, and admin inherits or overides fields/relationships from each of them in turn.

I may try adopting this into DMZ possibly using include_relations within the constructor but i don't want to hack your library up too much. The other thing is i've also invested a lot of time upgrading the original to do what i wanted and now my prob is I have a working version I like, and do i ditch it and go with DMZ or try to integrate it with the functionality you've developed? I thought it would be neat to release it as a Datamapper fork but i dunno if people need another DM library (plus i don't want to step on DMZ's toes ) Also if i were going to do that i'd have to write up my own docs and such and it IS a tremendous effort, i definitely give you props for your work there its really helpful.

anyway i'll continue thru the weekend checking out code and testing integration. I'll be awaiting the next release too, it seems like its making good progress and I like the features you're adding to it.

thx,

n

[eluser]OverZealous[/eluser]
I understand now. You want to include the columns from the Users table along side columns from the Person table when querying Users, in an automatic fashion, correct? Your User table would have, for example, a person_id column that represents which person that user is connected to?

You can create queries like that in DMZ pretty closely, just not 100% automatically (I'll get to that in a second...).

Here's the setup:

Tables

Code:

// people Columns
id, firstname, lastname, phone, email

// users columns
id, person_id, username, password, lastlogin, salt, person_id

Classes

Code:

class Person extends DataMapper {
    var $table = 'people';

    var $has_one = array('user');
    
    var $validation = ...
}

class User extends DataMapper {
    var $has_one = array('person');

    var $validation = ...
}

Controller

Code:

$u = new User();
// Include all of the related person columns (except ID, since it won't get overridden) in the results
// By passing FALSE for the 3rd arg, no prefix will be added
$u->include_related('person', '*', FALSE)->get_by_id($user_id);

echo($u->firstname . ' ' . $u->lastname);

To automate this, set up the user like so:

Code:

class User extends DataMapper {
    function get($limit = '', $offset = '')
    {
        // optionally, offer an override
        $this->include_related('person', '*', FALSE);
        parent::get($limit, $offset);
    }
}

You can even use the arrayutils extension to save information in just a few extra lines:

Code:

$user = new User();
$user->get($user_id);
if($user->exists())
{
    $user->person->get();
}
$user_result = $user->from_array($_POST, '', TRUE);
$person_result = $user->person->from_array($_POST, '', TRUE);
if($user_result && $person_result)
{
    // success
}
else
{
    // failure
}

Now, I understand this is only 1/2 of the problem (and the easy half at that). But I have an idea for a later version of DMZ (too late for 1.4.0). What if, instead of using class inheritance, I added a class variable called (for example), $inherit_from. This would accept a string value for the parent class.

Then (and this is the ugly part), DMZ could automate connecting the CRUD operations to the parent class. It would require a lot of work and testing, though. I'll put it on the "think about it" list.

(Of course, the easy solution is to just throw it all into the same table. Then you don't have to do all this rigmarole to glue two tables together.)

And I don't recommend forking it yourself unless you can give a lot of time to it. I've spent well over 20 hours updating documentation at this point, and probably several hundred hours in the updates, example app, and testing I've provided.

[eluser]ntheorist[/eluser]
hrm.. instead of a class variable you could do something like

Code:

$parent_class = get_parent_class($this);
if( FALSE !== strpos($parent, 'DataMapper') )
{
      // grab parent fields, validation etc & merge $parent_class with current model, fire joins etc.
}

i dunno. I may be trying to do too much. One of the problems i faced with this sort of 'inheritance' modeling is merging the validation array with that of its base class. It can be done with declaring them as static (which seems to fit since the validation array pertains only to its class model itself)
Again tho that's kinda changing everything around – and who knows how it would affect the rest of the methods.. If i were to ever attempt to setup a fork of DM it would need to at least be compatible with the original. I do love experimenting with it tho.

anyway i'm going to focus on tests with DMZ and possibly creating/porting extensions for it.

okay, dinner time! cheers

n

[eluser]OverZealous[/eluser]
That's why I wanted to avoid using class inheritance. It ends up getting really sticky.

I still say the best solution is to just mash it all into one table.

Maybe I could start using that as the basis for all DMZ projects:

Code:

objects
id, firstname, lastname, username, name, status, password, salt, title, description, user_id, editor_id, post_id, task_id, project_id, ...

Code:

class User extends DataMapper {
    var $table = 'objects';
}
class Project extends DataMapper {
    var $table = 'objects';
}
class Task extends DataMapper {
    var $table = 'objects';
}
...

:cheese:

Just in case someone doesn't get the joke:
Please, for heaven's sake, don't try this at home!

[eluser]ntheorist[/eluser]

Code:

$p = new Phil();
$p->include_related('joke')->get();
if( $p->joke->is_funny() )
{
   return 'lol';
} else {
    groan();
}

[eluser]bEz[/eluser]
@ntheorist

I've decided to adapt your code snippet with a subtle rewrite of my own.

[quote author="ntheorist" date="1248518303"]

Code:

$p = new Phil();
$p->include_related('joke')->get();
$s = new Smiley();
if( $p->joke->is_funny() )
{
   $s->where('id', '0')->get(); // :)
} else {
   $s->where('id', '9')->get(); // :(
}
return $s->code;

[/quote]

Seriously though.... I am just getting through rewriting an app ready for 1.3.2 to gear-up for 1.4 and would like to ease the mind on any need to rewrite for 1.5.x if possible.
However, I do enjoy the technical discussion laid out in the recent threads. And I too am just chopping at the bits to break ground on writing extensions.

[eluser]OverZealous[/eluser]
@bEz
By rewrite, do you mean just incorporating new features?

I try very hard to make sure that each version is fully backwards compatible (excluding "hackish" code). Is there something specifically that you had trouble with in 1.3.2 or in 1.4? I'd like to know, so I can keep an eye on those issues, and/or add them to the docs if they cause problems.

[eluser]bEz[/eluser]
nah Phil... it was a play on the joke before hand... i'm good with 1.3.x and 1.4.x

[eluser]naren_nag[/eluser]
Phil,

I just upgraded and was looking at the documentation and I felt I had to come and thank you for all the hard work you've put in, the library is fantastic, but the documentation takes it to a whole different level.

Well done!

Naren