[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition)

[eluser]Ninja[/eluser]
I never thought of checking it that way.. Thats a new approach. The closest ive come is to exclude the last client in a array. surely there must be a way to loop through all clients and exclude them.. Isnt it considered bad practice to use active record in Datamapper because isnt datamapper sapost to establish the relations.
I am using advanced relationships in datamapper and they are truly amazing this is what they look like in the models:

Code:

<?php
class Company extends DataMapper
{
    var $table = 'companies';
    public $has_one = array(
    'client_company' => array(
    'class' => 'client',
    'other_field' => 'company'
    )
    );

    
    function _construct()
    {
        parent::_construct();
    }        
}
?>

Code:

<?php
class Client extends DataMapper{
    
    public $has_one = array(
    'company' => array(
    'class' => 'company',
    'other_field' => 'client_company'
    )
    );
    
    function _construct(){
        
        parent::_construct();
    }
}
?>

They great because i am able to link through to any table using get_by_id($table_id) as long as it has the related tables id as an in table foreign key. This seems to be the only thing i cant seem to get working and its becoming extremely frustating.
But thank you so much so far...
Quick question... would it be possible to use the function exists() id tried it before but if statement wouldnt work in the foreach loop.

[eluser]OverZealous[/eluser]
@Ninja
First, you don't need advanced relationships in your example, Advanced relationships are only necessary when you want a different name for the relationship than the class name (ie: when editor and creator are both actually users). It would probably make more sense to use standard relationships:

Code:

class Company extends DataMapper {
    $has_one = array('client');
}

class Client extends DataMapper {
    $has_one = array('company');
}

You can, of course, keep client_company if you prefer the name.


Second, you don't need to use AR methods when using in-table foreign keys. DMZ is smart enough to determine what you mean to query. ntheorist's example is exactly the code that DMZ generates automatically. (This wouldn't have worked in the original DataMapper.)

However, in none of the above examples did I see the phrase client_company, which is how you have to refer to the client if that's the name you give the relationship. For example, if you wanted to get all companies without clients, it would look something like this:

Code:

$comp = new Company();
$comp->where_related('client_company', 'id', 'IS NULL');
// Optionally, if you prefer, this works:
// $comp->where_related_client_company('id', 'IS NULL');

Finally, to avoid querying multiple times, don't forget to use include_related liberally! For example, getting a list of Clients with all of the Company data at once:

Code:

$clients = new Client();
$clients->include_related('company')->get();

Then you can read the company data like so:

Code:

foreach($client->all as $client)
{
    echo("${client->name} works for ${client->company_name}");
}

Since DataMapper uses AR behind the scenes, you can mix them. However, it should never be necessary (especially with the upcoming release of 1.4.0), and I highly recommend against it, as you will almost always have problems maintaining the code later. Trust me, I've written some nasty queries.

[eluser]bEz[/eluser]
@phil Using 1.4-b3

I have setup a table with 1 relationship and 8 boolean values.
In the model, I have the validation setup for the 8 bools as

Code:

'blah' = array(
      'label' => 'Can Blah',
      'type' => 'checkbox'
    ),

And in the $form_fields array I have:

Code:

= array(
     'id',
     'relation',
     'blah',
     'blahagain'
     'blahdmz',
  );

Unfortunately, I am getting the value="blah", however, I need it to be "1"
If I place 'value' => '1' in the validation portion, it does nothing new.

If I add
array( 'value' => '1') to the $form_fields, it adds checked="checked" and value remains the same when page loads.

Is this the appropriate behavior, or is this a "bug" I need to log in the example app.

-bEz

[eluser]ntheorist[/eluser]
well i gotta admit I'm still using a modified version of the original Datamapper.. I'm playing around with DMZ but i don't think i'm familiar enough yet with it to know exactly what queries the new features generate but i'm getting into it. I'm gonna be porting over some features i've written for the old one (as extensions perhaps?) and see how they fit with it but i might wait til the full 1.4 version

@Ninja one little tip. you mentioned using get_by_id($table_id). I actually set up my models so you can pass the id to the constructor (its the exact same thing just one less line of code)

Code:

class Client extends DataMapper{
    
    public $has_one = array(
    'company' => array(
    'class' => 'company',
    'other_field' => 'client_company'
    )
    );
    
    function _construct($id = NULL)
    {
        parent::_construct();
        if( ! empty($id) && is_numeric($id) ) $this->get_by_id($id);
    }
}

$c = new Client(2); // get client id 2
$c2 = new Client($id); // pass from data
?>

The exists() method does nothing more than check if $this->id is empty, thus no record was loaded into it through a query. Another helpful one fer sure.

n

[eluser]OverZealous[/eluser]
@bEz
Well, it might not work for you, but it's the expected behavior.

The reason being that you can have more than one checkbox per input field name. In this case, the "value" of the checkboxes would need to be unique.

I could update the code so that a single checkbox gets a value of 1. I'll look into it. I have a few more tweaks in place for 1.4.0-beta4, so I might add this in.

HTML forms either send the field if it is checked, or doesn't send it if it isn't. One way around this (that I use) is to create a validation rule (called 'boolean') that looks like this:

Code:

function _boolean($field)
{
    $this->{$field} = ($this->{$field}) ? TRUE : FALSE;
}

I should probably include this with the default distribution. This will fix the problem, while still ensuring that only TRUE or FALSE get inserted into the database.

[eluser]OverZealous[/eluser]
[quote author="ntheorist" date="1248485746"]well i gotta admit I'm still using a modified version of the original Datamapper.. I'm playing around with DMZ but i don't think i'm familiar enough yet with it to know exactly what queries the new features generate but i'm getting into it.[/quote]

I can appreciate that, but this is the DMZ forum. If you post suggestions based on the original DataMapper, it might be confusing to new DMZ users.

I hope you switch to DMZ soon. You will find it to be a significant boost to your productivity, and it should increase performance noticeably (when DMZ features are implemented).

[eluser]OverZealous[/eluser]
Post Removed: 1.4.0 was released

[eluser]ntheorist[/eluser]
well i try not to suggest something unless i'm sure it wouldn't affect the rest of the functionality. That's why i issued caution to Ninja about using AR methods (even though DM & DMZ build on them) because i'm not 100% up to speed on the new stuff you've added - plus i thought she wasn't using join tables, which would require a different approach than standard relationship methods.

i see you implemented passing the id to the constructor its a helpful lil thing and i use it all the time so it'll make picking up DMZ much easier for me (and my existing code). I just downloaded DMZb4 and i haven't checked through the whole manual yet but it would be good to note that you need to pass the id through your model constructors to Datamapper for it to work but that's it.

anyway i'll be playing with this release and i'll let you know how it goes. Also i have a few ideas about related functions and such that i'd like to run by you if you're interested, as well as a couple questions coming down the line, i'm sure.

cheers,

n

[eluser]OverZealous[/eluser]
@ntheorist

DMZ supports not using join tables for $has_one relationships. That's probably the #1 feature about it, and what prompted me to rewrite DM the first time. It's referred to as "in-table foreign keys" in the docs. It does it without a single line of code on the developer's part.

Also, I just made a tiny change to DMZ's $id in the constructor trick (checking for empty, like yours), because I had missed it. I just replaced the ZIP on the server, so you can grab it again if you care. (The only difference is that new Object(0) won't run a query now.)

My version of the docs has had some significant updates from stensi's originals. It really pays to read through them, especially this release.

My plan is to go ahead and release 1.4.0 by Monday evening (US EDT), because I won't be around for a few days, and I really want to get this release in everyone's hands. Apparently, only about 10 people want to test the beta release. Maybe I'll trick them into testing it this way! ;-)

[eluser]ntheorist[/eluser]
yeah being able to avoid join tables when not needed is a plus. 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?

I'm going thru the docs at the moment so i wont ask too many questions which may be answered there. 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?

one quick question i had (looking at the code) - is how does DMZ process queries with joined relations? So say i want to get a list of users with their roles and their name from their profile. I call user and join roles and profiles and run get() and start listing users with the related data. Does it collect this in one query or does it have to query the relations on every user iteration? Does that make sense? I'm looking at the get() + _to_object() methods.

btw i gotta say i really like how you laid out the development src. I tried breaking DM up once, in three parts which extend each other and contained main, AR and base logic repectively. But i think i like your categorization better in combo with the build() function you have going.

Also I attempted to move the validation into a separate library, i think it was mentioned earlier in this thread; is that something you might implement in the upcoming releases? I think it would be a benefit in cases (like above) where you are just doing a 'read', and also it could be used by other parts of an app, or even replace CI's form_validation library altogether (heh, not a fan of it)

anyway, thx for all the hard work it looks great!

n