[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition)

[eluser]OverZealous[/eluser]
If you want to use Active Record, use Active Record. DataMapper is an ORM. It maps data onto objects. What you are suggesting is just to replicate the already highly-functional ActiveRecord class, just with a different name. The overhead of creating objects is very low, since they share just about all properties statically (except for the per-row properties).

I think the bulk-update method I suggested makes a lot of sense. It's easy, stays within the DMZ ideology, and can use the large library of already functional code. It even works with relationships automatically.

I don't see the need to add it to the core DMZ library. If you have a look at the source, you will see it is a very large, very complicated library already. The purpose of extensions was to help ease the burden on the core library, without sacrificing functionality. Also, this just isn't something people need very often. And, as you can see in my example, it's extremely simple to use the normal AR methods with DMZ models.

[eluser]ben_co[/eluser]
I totally agree with your point of view about easiness and DMZ ideology (and I already took a look at the code ;-) ).

But in my suggestions examples nb 2, 3, 4 and 5, the $record(s) variable can be considered as DMZ Models. You could use the power of DMZ on it. I was just talking about a more structural way to code it with DMZ, not another CI ActiveRecord way.

I know it's a bit different with the natural DMZ way but I was wondering why we should create an DMZ model instance to do bulk operations for instance. Moreover, if we were totally working in PHP5, the bulk update could be declared as a static method.

Code:

DMZModel::bulk_update($params);

[eluser]OverZealous[/eluser]
[quote author="ben_co" date="1250950981"]I know it's a bit different with the natural DMZ way but I was wondering why we should create an DMZ model instance to do bulk operations for instance. Moreover, if we were totally working in PHP5, the bulk update could be declared as a static method.

Code:

DMZModel::bulk_update($params);

[/quote]

But now you've lost the ability to use the large amount of built-in functions. How do you handle relationships? How do you specify what is updated without reinventing the wheel? In your static example, there is no way to specify which rows need to be updated.

By using an extension like my example, you get to write code like this:

Code:

$user->articles->bulk_update(array('have_read', TRUE));

$newstype = new Type(3);
$twoweeks = 1209600;
$articles->where_related('type', $newstype)->where('created <', time()-$twoweeks)->bulk_update(array('oldarticle', TRUE));

It might be better to name it "update_query" or "update_all", or even just simple "update". I'll have to think about it, because I can see it's use more and more. The only thing my example doesn't handle (currently) is allowing you to easily use functions (they must be specified manually).

Are you simply not wanting to create the object manually? It's only one line to create the object, and it opens a wealth of options. And there is no additional overhead in using the standard DataMapper model for updates. You have to instantiate at least one copy of every model just to figure out what the table name is.

[eluser]ben_co[/eluser]

Are you simply not wanting to create the object manually?

Exactly. In my examples, I would only create objects when I work on a specified (set of) records. For bulk (update or delete), we shouldn't need in my opinion to create an empty record because we don't want to populate it with/or execute a query on a resultset.

You have to instantiate at least one copy of every model just to figure out what the table name is.

I know that. It's why in my examples my code would behave like this:

Code:

$this->datamapper->load('articles');

$newstype = new Type(3);
$twoweeks = 1209600;

$this->articles->where_related('type', $newstype)->where('created <', time()-$twoweeks)->bulk_update(array('oldarticle', TRUE)); ;

But I admit that $this->articles is in fact the same that $articles = new Article();

The second problem is that save() and delete() shouldn't be callable directly in my opinion. It should be only when we plan to create a new record or modify an existing one. In the following example, these methods are useless.

Code:

$this->articles->delete(); // equivalent to: $article = new Article(); $article->delete();

delete() should delete all the articles, not throw an error about 'no record selected'.

And in this last example,

Code:

$this->articles->new_record(); $article->delete();

delete() would throw error about 'not specified datas' only.

I hope my explanations are clear ;-).

To sum up my ideas, on one hand, when we create a DMZ model instance, we should only apply bluk operations.
On the other hand, specific save() and delete() are available when we manipulate (a set of) existing (or new via the create_new() method) records based on the DMZ model definition. DMZ model definitions should so be considered as a singleton class (and only as a factory).

Finally, maybe it's just a problem of notation habit :-). Never mind, forget that ;-) !

[eluser]OverZealous[/eluser]
@ben_co
Hopefully I didn't drive you off, but I wanted to let you know that I added the update method to the very-soon-to-be-released DMZ 1.5.0. This method, I think, is going to be very useful for a lot of people. I do appreciate the feedback you provided in thinking it through.

I still can't safely enable bulk deletes, because there is no way to delete the relationship information simultaneously. Since there is no reason someone can't still use the CI ActiveRecord methods, I think this is a fair compromise. If you are OK with the risk of DB corruption, then you can run it manually.

This update also includes the ability to run validation-like rules after a get, fixes many bugs, and several other new features that have been asked for.

I've made some changes that have repercussions (such as renaming several of the included extensions), so I had to bump the version by 0.1, instead of 0.0.1.

[eluser]Daniel H[/eluser]
Looking forward to it - when do you reckon it'll be released?

Does it fix the multiple include_related bug mentioned a few bugs back (negating the need to preload)?

[eluser]OverZealous[/eluser]
Yup, fixes all of those. I hope to have it out this morning (ie: next 3-4 hours). There ended up being more changes than I had remembered, so updating the docs has taken some time.

[eluser]Daniel H[/eluser]
Very exciting! Cheers Phil.

[eluser]ben_co[/eluser]
@OverZealous Thanks for the bug fixes and for your precious work !

[quote author="OverZealous" date="1251205307"]
I still can't safely enable bulk deletes, because there is no way to delete the relationship information simultaneously. [/quote]

If I caught correctly what you would mean, I think this kind of problem may also appear in the update case. Indeed, when you are ready to update relationships, we don't know if the old related elements must still exist in their database table or if these must be also deleted before setting totally new ones. In fact, I started to code yesterday this extension :-P ... To handle this kind of problem I recursively checked for relationships in the target model and then apply methods sequentially to each related object (and sub-sub-sub-related if needed). The only problem is that these calls can't be done in a whole, so maybe I should use transactions to handle that correctly. Maybe there are others solutions... (I don't know if using sort of "CASCADE" effect is possible here in terms of DB).

[eluser]OverZealous[/eluser]
@ben_co
You are correct that a similar problem can occur. However, because update is very limited (you'll see when I release it), it's much less of a risk.

The update function I'm including will mostly be used for mass updating a table, such as incrementing columns, or replacing NULL values, etc.