DMZ 1.7.1 (DataMapper OverZealous Edition)

[eluser]Daniel H[/eluser]
Hey Phil - in the roadmap you mention:

Add hooks for extensions, so they can directly modify core functions (like get, save, and delete).

How far along is this? I'm super keen to hook into save() to keep a log of changes to a object, but don't fancy hacking away at the core. :-)

[eluser]WanWizard[/eluser]
I needed something similar, my workflow engine allows triggering a workflow by table operations (p.e. insert of a new user).

As DMZ uses the standard CI Active Record methods, I solved this in my AR extension, by overloading the insert, update and delete methods. A hook would have been easier though, as extending the database classes requires core hacking too...

[eluser]OverZealous[/eluser]
I'm sorry to say that I haven't had any time to work on DMZ since around mid April.

I'm still in a tough transition phase, living in a different state than my wife and working at a new (and demanding) job.

Most likely my next updates, to which I can not commit a timeframe, are going to revolve around simple bugfixes, and minor improvements to the core. Something like adding extension hooks is going to take a bit of time, so it won't necessarily be coming in the near future. That being said, I'm pretty sure I've already determined out how to implement it with minimal impact to the library's performance.

[eluser]matyhaty[/eluser]
Im come across a very strange error, which i cant make heads of tails with, when using the include_related advanced get.

So, i'll brief try to explain.

I have a tables called 'tasks', 'flags' and 'surveysFurnitures'
I have the relationship tables: 'flags_tasks' and 'surveysFurnitures_tasks'

Tasks has a

Code:

var $has_one = array("flag", "surveysFurniture");

SurveysFurnitures has a:

Code:

var $has_one = array("task");
        var $table = 'surveysFurnitures';

And Flags has:

Code:

var $has_many = array("task");

Relating and accessing task to flag information works fine, no problems.
Using the code,

Code:

$task = new Task();
        $task->where('id', $pointNumber);
        $task->include_related('surveysFurniture', NULL, TRUE, TRUE);
        $task->get();

relating tasks to surveysFurnitures generates this error

A Database Error Occurred

Error Number: 1054

Unknown column 'surveysfurniture_surveysFurnitures_tasks._id' in 'on clause'

SELECT `tasks`.*, `surveysfurniture_surveysFurnitures`.`id` AS surveysFurniture_id, `surveysfurniture_surveysFurnitures`.`pointNumber` AS surveysFurniture_pointNumber, `surveysfurniture_surveysFurnitures`.`easting` AS surveysFurniture_easting, `surveysfurniture_surveysFurnitures`.`northing` AS surveysFurniture_northing, `surveysfurniture_surveysFurnitures`.`section` AS surveysFurniture_section, `surveysfurniture_surveysFurnitures`.`location` AS surveysFurniture_location, `surveysfurniture_surveysFurnitures`.`defectTo` AS surveysFurniture_defectTo, `surveysfurniture_surveysFurnitures`.`damage` AS surveysFurniture_damage, `surveysfurniture_surveysFurnitures`.`priorityID` AS surveysFurniture_priorityID FROM (`tasks`) LEFT OUTER JOIN `surveysFurnitures_tasks` surveysfurniture_surveysFurnitures_tasks ON `tasks`.`id` = `surveysfurniture_surveysFurnitures_tasks`.`_id` LEFT OUTER JOIN `surveysFurnitures` surveysfurniture_surveysFurnitures ON `surveysfurniture_surveysFurnitures`.`id` = `surveysfurniture_surveysFurnitures_tasks`.`_id` WHERE `tasks`.`id` = '1'

Any ideas at all from anyone?

Many Thanks

[eluser]jpi[/eluser]
Quick thought : it could be a problem with case sensitiveness. Try to rename surveysFurnitures to surveysfurnitures

[eluser]matyhaty[/eluser]
It was the case sensitive.
Surely that should be
- documented as a bug [or]
- made aware in the manaual not to use capitals

[eluser]WanWizard[/eluser]
The manual states (general topics, database tables):

Normal tables must be named the lowercase, pluralised version of the object name

which I guess means "don't use capitals"...

[eluser]Colm Ward[/eluser]
I've encountered the same bug in DMZ as was already reported by @uptime last month.

If you use include_related with the instantiation option set to true, the related object does not instantiate in PHP 5.3.2 or 5.3.3 (which is the most recent).

It is not an issue in PHP 5.3.0 or 5.3.1. These four are the only versions of PHP I've tested it with. Ive not seen any other problems with DMZ in these most recent versions of PHP.

cheers
Colm

[eluser]TheJim[/eluser]
[quote author="Colm Ward" date="1281360924"]If you use include_related with the instantiation option set to true, the related object does not instantiate in PHP 5.3.2 or 5.3.3 (which is the most recent).
[/quote]

Funny that you would post this. I just barely had this problem with taking a site live on a server using PHP 5.3.2. Where the problem occurs is with the _to_object function starting on line 5923:

Code:

foreach ($this->fields as $field)
{
    if (! isset($row->{$field}))
    {
        $item->{$field} = NULL;
    }
}

It looks like PHP >= 5.3.2 doesn't like using arrays with the object reference syntax (as pseudo-objects), and objects being instantiated from include_related have their values set up in an array. So the object is instantiated and set up with the proper values, and then the loop above sets everything back to NULL.

So, the simple fix is to change the code below (comment starts on line 5949)

Code:

// convert fields to a 'row'
$row = array();
foreach($field_map as $item_field => $c_field) {
    $row[$c_field] = $item->{$item_field};
}

to use an object for the values to assign:

Code:

// convert fields to a 'row'
$row = new StdClass();
foreach($field_map as $item_field => $c_field) {
    $row->$c_field = $item->{$item_field};
}

That should take care of it.

[eluser]TheJim[/eluser]
And I probably should have actually read uptime's post. Anyway, take your pick of fixes.