DataMapper ORM v1.8.2

[eluser]tarciozemel[/eluser]
[quote author="WanWizard" date="1331855027"]@tarciozemel,

Datamapper passes where() clauses unaltered to $this->db->where(). Maybe something changed in CI's DB drivers?

You can try

Code:

...
$companies->where('MATCH (foo) AGAINST ("bar" IN BOOLEAN MODE)', NULL, FALSE);
...

which will disable escaping...[/quote]

Your tip did the job! Thank you!

PS: Sorry for my delayed response, but some times the forum system not send me the message alert email...

[eluser]WanWizard[/eluser]
[quote author="North2Alaska" date="1331914600"]BTW: I was out looking at the 2.0 version but nothing has change for a few months. Is progress still being made? I'm going to be doing a lot of DM and would like to contribute in some way.
[/quote]
I started it because I wanted to do a full rewrite to deal with the 2.0+ changes in CI, and the fact that the DM code is getting dated (and got a bit bloated over the years).

But currently it works, and I don't have time for it. Bread on the table and my work for Fuel goes first at the moment.

[eluser]Ikkes[/eluser]
@WanWizard

I have downloaded the latest DataMapper as you told me. The script is working very fine now :-)

Thank for your help.

With kind regards,
Dennis

[eluser]North2Alaska[/eluser]
@WanWizard

I think @Ikkes and I are in parallel universes or something... :-)

I have installed the most recent version and all is working well.

Thanks for all the help!

[eluser]WanWizard[/eluser]
Cool. These are the best problems to fix...

[eluser]North2Alaska[/eluser]
As I begin to learn DM, I have a question about overriding the table name with either the $prefix or $table variables. Is there any disadvantage to doing the override? Why not just create the model and specify the table

Class User extends DataMapper {
$table = 'MyUserTableForAuthorization';

}

Will something like this have any overall negative impact? Or is it just one more thing to have to remember?

[eluser]North2Alaska[/eluser]
And another one.

I love the auto entered create and update datetimes. I want to extend the functionality to include the id of the current user. I've been looking at the save function, but I don't see a good way to implement it. Ideas?

[eluser]North2Alaska[/eluser]
[quote author="North2Alaska" date="1332016966"]As I begin to learn DM, I have a question about overriding the table name with either the $prefix or $table variables. Is there any disadvantage to doing the override? Why not just create the model and specify the table

Class User extends DataMapper {
$table = 'MyUserTableForAuthorization';

}

Will something like this have any overall negative impact? Or is it just one more thing to have to remember?[/quote]

Well, I see the first challenge. When using a relationship, the many to many table takes on the table name so, if I have two tables, auth_user and auth group and they are joined by another table, I named it auth_group_user, DM looks for a table'auth_role_auth_user'. It's not the preferred, but I can live with it.

But if I set the $prefix instead of $table, then I get more what I expected, auth_roles_users. This is better and I think I will go with this one.

[eluser]WanWizard[/eluser]
There are several prefixes at play here.

The first one is the one defined in the CI database definition, and is used application wide, and that includes Datamapper. You use this prefix if you store non-CI-app tables in the same database, and you want to make sure you have no collisions.

The second one is the one defined in the datamapper config file. It will be applied to all tables accessed by Datamapper through the models. It is mainly handy if your application has a mix of Datamapper and non-Datamapper tables, and you want to separate the two (again, to avoid collisions).

In this situation you might want to use the per-model prefix to override the second one, usually to set it to "" (empty string), so the model can access the table without Datamapper prefix (for example because it is a table shared with the non-DM part of the application).

I have never encountered a situation where the per-model prefix was used to set some other prefix. The only use-case I can think of is that you have several Datamapper driven applications using the same database, no CI prefix is defined, and the global Datamapper prefix is used to separate the application tables. You can then use the per-model prefix (for example for a users model) to share tables between applications by setting the prefix for this model the same in all applications.

I don't have a problem using some second 'prefix' in the table name to group tables within the database. I usually do that in a modular design (I prefix with the module name), again to avoid collisions. For an authentication module, I would indeed have table names starting with 'auth_'.

If the CI prefix is then 'CI_', the Datamapper prefix 'DM_', the table name would be something like 'CI_DM_auth_users'. I can live with that (it makes it absolutely clear what it is), and I don't really have a problem with the fact that this would create 'CI_DM_auth_groups_auth_users' as relationship table. If you have an issue with this, you can name the relationship table using the 'join_table' field if you use advanced relationship definitions.

[eluser]WanWizard[/eluser]
As to the question about timestamps, just overload the save() method in your model:

Code:

// your model
public function save($object = '', $related_field = '')
{
    // check if object has a 'created' field, and it is not already set
    if (in_array($this->created_field, $this->fields) && empty($this->{$this->created_field}))
    {
        $this->{$this->created_field} = 'add your custom data here';
    }

    // and call the DM save() method to save the object
    return parent::save($object, $related_field);
}

You can do the same with other fields or methods. There are users that have overloaded several methods to implement soft delete functionality, where records are not deleted but marked as deleted.

If you want to use this for multiple models, create a base model for it:

Code:

class Basemodel extends Datamapper
{
    // your base model methods here
}

class User extends Basemodel
{
   // your normal model info here
}

Now your User model will inherit all methods defined in the Basemodel, as well as all methods in the Datamapper class.