Thread

I understand when updating a record DM will run query only against the fields that changed. Is there a method in DM to determine what those fields are. I want to log fields that changed (field: old_value -> new value). I could write this in a controller but maybe DM has something to offer?

The method is a private one, called _changed($field).  You simply call it with the name of the field BEFORE you save, and it checks against the database.

Note, however, that it runs a small query against the DB for each field to determine if it has changed.  It may be a performance problem.

Also, since it is a private method, there is no guarantee it won’t work differently, or be removed altogether, in a future version.  😉

Thanks for the tip, that’s exactly what I was looking for.

For performance purposes, should I index both columns in the join_tables (eg. employee_id and company_id in table join_employee_company)?

Thanks!

I don’t know about your database engine, but I’ve always been told that, unless you are dealing with really big tables, the database engine usually doesn’t even use the indexes.

IE: you can add the indexes, but they add a cost when writing that might not be beneficial during reads.

You replied in two minutes! Sweet! Go CI community!

I am auto loading the datamapper model as explained in the first page of this post. But doing so gives me the error:

The model name you are loading is the name of a resource that is already being used: datamapper

Can any body explain me what happend?

Just wanted to say this is a fantastic contribution, the documentation is brilliant (which makes all the difference) and the functionality and cleanness of how it works is brilliant, this functionality is something that was an advantage for CakePHP when i had a dabble in it, so keep up the good work!

@Aukie
The latest release of DataMapper is a Library.  It therefore needs to be autoloaded as a Library, as well, but not loaded as a model now.

The DataMapper documentation has this updated better: http://stensi.com/datamapper/pages/installation.html

@Aukie
The latest release of DataMapper is a Library.  It therefore needs to be autoloaded as a Library, as well, but not loaded as a model now.

The DataMapper documentation has this updated better: http://stensi.com/datamapper/pages/installation.html

Thanks OverZealous,
I made a little mistake thats why it did not work and looking for solutions found out in this forum I had to load datamapper as model…

Thanks, datamapper looks cool, let’s see if it is indeed a realy big advantage.

It’s been a huge advantage for me (although, you really need to design FOR datamapper).  I love being able to almost “ignore” the database in my code.

Good Luck!  Feel free to come back if you have any questions.

You are fast in your replies Phil (Guess thats your real name no?!)
That will be appreciated by many!

I am still wondering what the real advantage is.

Normaly I would make some models who will handle a certain scope of information from the database.
For instance I am working on a real estate website I have user related database tasks and real estate tasks so I have two models with various functions handling database tasks. I than return database objects to my controlers who process and gather the information and serve it to my views.

With datamapper I will have more than two models.
The code is somewhat different from that of codeigniter but not even that big.
I must say I almost always use $this->db->query(  ) serving a normal sql query.

As you can see I have not grasped the benefit of using datamapper.
You are wrote “need to design FOR datamapper” to get the real advantage. Do you mean like the naming convention for tables etc?

Is it a conveniance improvement or a real advantage, in using datamapper?

Can you learn me what the advantage realy is in using datamapper, what can you tell me about it?
Next thing i wonder is speed, how is datamapper performance v.s. plain old php mysql queries…

Love to learn!

The real advantage is in development time.  I don’t know how much performance matters, and I won’t have answers to that for some time yet, due to the kind of project I am developing.

Where DM shines is in reducing code complexity.  For example (I don’t know your project, so this is just a guess),

// get all real estate properties for this user
$user = $this->session->logged_in_user;
$properties = $user->properties->get();

I think that is significantly easier to read and work with than the more traditional method.  (I won’t bother writing that out, but you can guess, running a query, parsing the results, storing them into some kind of temporary object or array, or - shudder - passing the results array directly to your view.  😛 )

Where you have to be “careful” is in your application design.  Not only tables, but sometimes you might have to rethink something that would be a very complex SQL query.  Because DM doesn’t allow you to write your own queries, you can sometimes end up running several queries behind the scenes instead of one compound query if you wrote it by hand.

Personally, I think the trade-off is worth it.  I’m building a project that would normally take me 2x as long, or require extra people, and I’m doing it on my own.  I think DM & CI are really helping chip into that time.

(I live in front of my computer.  That’s why the response times are so quick 😉 )

Thank for you answer Phil!

So it is indeed more of a conveniant thing.
I do like conveniant tools and solutions to make my live easier 😉

I must say that I think that a function in my model like below is easy to write, use and read though.

public function get_objects( $type, $perPage=6, $ofSet=0 )
{
   $sql = "SELECT id, host_id, area, price, image1 FROM objects WHERE type_id IN (".$type.") LIMIT ".$ofSet.", ".$perPage;

  $query     = $this->db->query( $sql );

  if( $query->num_rows() > 0 ){

    return $query;

  }else{

   return FALSE;

  }
}

Certainly that’s easy.  Except when you need to add another object type.  Or another field to your object.  With DM, you can add fields to the DB and have access to them immediately in the object.  Of course, it’s better to throw them into the validation array as well, but that’s a minor thing.

Finally, because it’s object oriented, you can start getting really creative with your objects.

For example, say you have a contact with multiple phone numbers, but one number is the “Default”.  Every time you change the default, you need to unset the previous default.  In DM, you can add this to your model:

// in class Phonenumber
function set_default() {
    // gets all other default phone numbers
    $others = $this->contact->get()->phone->where('default', TRUE)->get();
    foreach($others->all as $o) {
        $o->default = FALSE;
        $o->save();
    }
    $this->default = TRUE;
    $this->save();
}

Now, that’s a few lines of code, but it’s associated with the model now.  What I like is how clean that is to read when you use it later:

$phone->set_default();

As opposed to:

set_default_phone($contact, $phone);

If you aren’t used to the OO way of programming, it takes some time to see how it cleans up the code.  (It looks like you are more used to functional programming, given your function design 😉)

Also, you don’t have to worry about function names too much :cheese:

Finally, I’m not ready to release it yet, but I’ve developed a really slick way to automatically convert DM objects into form fields or html-ready views.  For example, you can get a date-editing field simply by using:

echo($task->e->datecompleted->date);

And it will automatically print out a date field.  With a few minor changes to the DM model, you can even eliminate the ->date at the end.  Replacing the ->e with ->v will render the date as formatted text, instead.  This only works because of the self-aware nature of DM models.

I’ve got it working for almost every common DB datatype, as well as some specialty items (like email addresses or web links).  The only big caveat is that I’ve written mine around Dojo and Dijit, which not everyone uses.