[Deprecated] DMZ 1.6.2 (DataMapper OverZealous Edition)

[eluser]OverZealous[/eluser]
@Peet86

Short answer: No, but you should read below.

Join fields don't allow you to make multiple relationships between the same object. They are only there to provide additional information about the relationship. You can still only make one specified relationship type between two objects.

If you need multiple relationships between two objects, there are two ways it is supported. If you have a known, small number of types, then you can define multiple relationships per pair of objects. This might not be optimal, because it becomes harder to query the entire set.

The other way is via a third object that exists specifically for the join. You'll actually be able to use your existing join table as the new object (you just will have to rename it, and make sure you have an ID column).

The second option is a lot more flexible, but it will take a little bit more planning.

[eluser]OverZealous[/eluser]
[quote author="Mosselmaniac" date="1266791027"]
Is it possible with this ORM to generate the objects from the database-definition?[/quote]

No, DMZ does not have any sort of automated builder, in either direction. You will need to set up the database, then also define your classes. (It does pull in the database columns as fields, but that is almost irrelevant, because you'll need to specify any rules on those fields separately.) DMZ is a fairly simplified library for ORM.

At some point I still would like to develop a tool to help generate the models, but I do not currently have the time to build something the way I would want it to work.

[eluser]Peet86[/eluser]
Thank You Phil!
The second option is good for me.
Peter

[eluser]Mosselmaniac[/eluser]
Thanks for your fast reply.

What do you advice me to do? I'm currently 'blank'. I realise when I choose an ORM (and framework for that matter), I will be bound to it for at least this specific project. That's the reason I would like to make the right choise in this phase. To be honest, i'm looking for some longer-term-relation with an ORM ;-)

How do you handle this in practise? You model a new attribute to an existing entity in your database, jump to the representing model, and add it there too? Do you think there is much overhead there? Should this be a reason for me NOT to use DMZ?

[eluser]OverZealous[/eluser]
Mosselmaniac

As the developer of DMZ, I'm not really the best person to ask. DMZ works great for me.

Personally, I think one of the least important aspects of an ORM is the initial setup. By that I mean you only set up the database once. You only write that inital model code once. After that, at least 95% of the work is in using the ORM. DMZ has a lot of built in functionality for making complex queries simple. The manual and download includes a lot of examples, so you can see how it functions in practice, not just in theory.

But I'm not a hard pusher for DMZ. I'm glad a lot of people use it, but I also don't have any real experience with other PHP ORMs.

I will warn you, since this might be annoying in the next week or two when I release the next update to DMZ, I'm no longer supporting the HTMLForm extension. It works pretty good as is, but I decided I cannot support two large projects right now. This extension is used throughout the examples to generate forms, so just be aware of that. (It still works, and has no bugs that I am aware of, I'm just not supporting it.)

The other extensions are fine, however.

[eluser]Conerck[/eluser]
[quote author="Mosselmaniac" date="1266793169"]How do you handle this in practise? You model a new attribute to an existing entity in your database, jump to the representing model, and add it there too? Do you think there is much overhead there? Should this be a reason for me NOT to use DMZ?[/quote]

In DMZ you would only have to touch your database table. The model classes work with PHP's magic functions for getters and setters so you don't need to re-declare the fields in the model class (unless you want/need some validation rules for that field) and you can just start accessing the new attribute in your code right away.
This is somewhat of an advantage for rapid developement, in my opinion, but it also has it's drawbacks. For example you can't rely on code completion in your IDE to make sure that you spell the field names correctly and so on.

But as Phil said, the initial setup and model configuration time should be secondary to your decision, unless you are just looking at hacking up a quick prototype / proof-of-concept. After all, you generally spend more time writing actual application logic and algorithms than defining and changing your models.
You should carefully look at requirements and the feature list of your application. If you just need a simple and reliable way to access some relatively simplme structured data objects, go for CodeIgniter. If you plan on having a more complex database design with alot of deep linked relationsships and/or need complex queries that require alot of manual query optimization or unusual structures and joins you might want to look at a more complex framework that is better at supporting those things.

[eluser]NachoF[/eluser]
Hey Phil, have you read about the Repository pattern??? what do you think of it? is it fit for Datamapper?

[eluser]OverZealous[/eluser]
@NachoF
I have not heard of it. Do you have a link or some more information?

Otherwise, my answer is, it would probably work great as an extension.

[eluser]selfkill[/eluser]
For anyone who needs to have a different class and table names, I've found a somewhat hacky solution that has worked so far.

For example, I usually like to name my model classes with a "_model" at the end, so they don't muck up the namespace. So for a model named User_model with a table name of "users" I would do:

Code:

class User_model extends DataMapper {
    public $model = 'user';
    public $table = 'users';

...
}

If User_model has a relationship with another model named Group_model, I do this:

User_model:

Code:

class User_model extends DataMapper {
    public $model = 'user';
    public $table = 'users';

    public $has_one = array(
        'group' => array('class' => 'Group_model')
    );
...
}

Group_model:

Code:

class Group_model extends DataMapper {
    public $model = 'group';
    public $table = 'groups';

    public $has_many = array(
        'user' => array('class' => 'User_model')
    );
...
}

I haven't had a chance to test this a lot, but so far this seems to work. If it is a viable solution, perhaps it should be added to the FAQ because I had to do a lot of Googling to figure this out. As a feature request, I would like it if there was one simple way of specifying a different class name from a table instead of doing it like this. Until then, this seems to be the only way of going about it.

[eluser]OverZealous[/eluser]
@selfkill

Well, this is mostly explained in DataMapper Models, as well as answered in the Troubleshooting question Why is DataMapper generating the wrong table name?

However, having a significantly different class name and model isn't officially supported. The purpose of the $model property is for the cases where running singular() on the classname improperly converts it.

It's not really a good idea to have your classname be so different from your model/table name, and I cannot guarantee that you won't have problems with the more advanced features of DataMapper.