[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition)

[eluser]OverZealous[/eluser]
DataMapper OverZealous Edition 1.5.0 Update

[quote author="OverZealous" date="1240964466"]Version 1.5.0:

Core Changes:
• New update method can be used to perform updates on multiple objects at the same time.
• New get rules that are run immediately after getting data from the database.

Extension Changes
• Extensions can be have prefixes on the class name to prevent naming collisions.
• arrayutils and csvutils are now simply called array and csv, respectively. The old names will not receive any new updates.

Improvements
• Customized trim prepping rule that doesn't convert empty values into strings.
• New Custom validation rules can now return an error message directly, instead of relying on language files (or setting the error, but returning TRUE).

Bug Fixes
• Fixed several bugs in specific related queries.
• Fixed several bugs related to the auto_populate commands.
• Count always returns an integer.

Because some of these changes may cause issues with existing code, this is a point upgrade. Please be aware that some of these updates may adversely affect existing code, and of the extension changes.
[/quote]

Download the Latest Version Here

View the change log and the upgrade process
Having issues? Please look through the Troubleshooting Guide & FAQs
View the Complete Manual

[eluser]macigniter[/eluser]
Thanks to your suggestion I figured out how to make the best use out of the join_fields. Nevertheless I have one more question to ask...

Code:

join_offices_users
- group_id
- office_id
- user_id

Is it possible to populate (and query) the join_field 'group_id' WITHOUT having a relationship to an office?

[eluser]mcnux[/eluser]
I'm having trouble with non-standard models. All I want to do to start with is change the name of my model to something other than the singular name of the table.

Here's my models:

Code:

class Base_list extends DataMapperExt{
  var $table = 'lists';
  var $has_many = array(
    'list_item'=>array()
  );
}
class List_item extends DataMapperExt{
  var $has_one = array(
    'base_list'=>array()
  );
}

Tables are something like:

Code:

lists
=====
id
title

list_items
==========
list_id
title
content

The problem occurs when I attempt to access list_items. In my application when I do something like:

Code:

$list = new Base_list($id);
$listItems = $list->list_item->get();

I get the following error:
Table 'jms.list_items_lists' doesn't exist

Looks like for some reason DMZ isn't checking for the list_items table and instead is assuming I'm using a join table for the relationship?

(updated)

[eluser]OverZealous[/eluser]
[quote author="macigniter" date="1251306892"]Is it possible to populate (and query) the join_field 'group_id' WITHOUT having a relationship to an office?[/quote]

No, because the table is really showing the relationship between offices and users. Therefore, a row only exists if there is a relationship between an office and a user.

There are two ways to handle that:
1) Use the other method I suggested, having a dedicated class to represent the 3-way relationship. This would be a little tedious, because it sounds like you already have some work put into this.

2) Add a group_id column to the users table. Then you can populate this manually for users that have no office or for the non-office group. Of course, you can't easily query this group the same time as you query the other one.

[eluser]OverZealous[/eluser]
[quote author="mcnux" date="1251315465"]Looks like for some reason DMZ isn't checking for the list_items table and instead is assuming I'm using a join table for the relationship?[/quote]

DMZ is checking correctly. You've just got the wrong name for your column. :-)

If the relationship is called 'list_item', then the in-table foreign key column is called 'list_item_id'.

DMZ always uses the relationship key (which is usually the class name) for determining ITFK names. Otherwise, you couldn't have more than one relationship to the same object.

FYI: If you aren't working with advanced relationships (where you need to specify a class name, etc.), you don't need to include the empty array in your $has_one or $has_many properties. Simply write it like this:

Code:

var $has_many = array( 'list_item' );

[eluser]pdswan[/eluser]
@OverZealous

Using the the select method without specifically selecting the id field results in an incorrect listing of results:

Code:

$i->select('title')->get();

only gives 1 result because _to_object tries to add the object to items with it's id as the index, but the id is not defined:

Code:

datamapper.php line 4375: $items[$item->id] = $item;

you would think that if $item->id was NULL

Code:

$items[$item->id] = $item;

would be equivalent to

Code:

$items[] = $item;

but instead it seems like it continually overwrites the NULL index of the array.

i temporarily patched with

Code:

if( $item->id ){
    $items[$item->id] = $item;
}else{
    $items[] = $item;
}

[eluser]OverZealous[/eluser]
[quote author="pdswan" date="1251329541"]only gives 1 result because _to_object tries to add the object to items with it's id as the index, but the id is not defined [...][/quote]

This has been an issue leftover from the original DataMapper. I don't know stensi's original thought on this, but I never changed it, because I was afraid it would break existing code (since it's effectively adding DISTINCT to every query).

I had always planned on removing it when I got DMZ to 2.0.0, because a major version change is usually safe for big fixes.

However, your solution is a great interim solution. I'm definitely going to adopt that, and it will be included in 1.5.1!

Thanks!

[eluser]Muser[/eluser]
[quote author="OverZealous" date="1249955461"][quote author="tdktank59" date="1249953004"]Thats a little too much out of my way to do it that way. Im loading up 5 drop-downs that all need these types of options...[/quote]

Well, I don't think it's that much work. If you were doing this the old way it would be way more work than even that.

You don't have to hack it, anyway. Just write your own drop-down method. As long as it is named input_mymethod, and available, you can write your own code. You can easily write it to simply add the first row to the list, then pass everything back to the HTMLForm class.[/quote]

I am trying to get it done adding a new input type:

Code:

function input_mydropdown($object, $field, $value, $options)
{
    array_unshift($options['list'], array( 0 => '-- Select --'));
    return HTMLForm::_input_dropdown($object, $field, $value, $options);
}

But, I get the following error:

Fatal error: Using $this when not in object context in C:\webs\xampp\htdocs\grera\application\datamapper\htmlform.php on line 571

[eluser]OverZealous[/eluser]
That's because _input_dropdown is not a static method of the HTMLForm class.

Off the top of my head, I'm not sure what the best solution is. I guess for now, you'll need to instantiate a new HTMLForm class, and then call it on that instance. The overhead should be minimal, unless you need it more than (say) 10 times on one page.

Code:

function input_mydropdown($object, $field, $value, $options)
{
    array_unshift($options['list'], array( 0 => '-- Select --'));
    $hf = new HTMLForm();
    return $hf->_input_dropdown($object, $field, $value, $options);
}

Another option for you would be to "extend" HTMLForm as your own class, then use that extension. I'd try something like this:

Code:

include_once(APPPATH . 'datamapper/htmlform.php');
class myHTMLForm extends DMZ_HTMLForm // v1.5.0
{
    function _input_dropdown($object, $field, $value, $options)
    {
        array_unshift($options['list'], array( 0 => '-- Select --'));
        return parent::_input_dropdown($object, $field, $value, $options);
    }
}

Then just load in the extension 'myhtmlform', or whatever you choose call it.


I admit, I really haven't spent enough time making HTMLForm itself extensible. It takes a lot of work just writing the extensions in the first place. I also have to admit, I don't use the extension myself! :-) This is because I have a lot of legacy code I don't have time to refactor.

Let me know if one of these options works for you. In the future, I'll create a better way to extend HTMLForm, but I have other projects on my plate right now.

[eluser]mcnux[/eluser]
[quote author="OverZealous" date="1251324145"]
DMZ is checking correctly. You've just got the wrong name for your column. :-)

If the relationship is called 'list_item', then the in-table foreign key column is called 'list_item_id'.
[/quote]
I think what you meant to say was as the model is called 'base_list', the ITFK on list_item should be called 'base_list_id'.

[quote author="OverZealous" date="1251324145"]
DMZ always uses the relationship key (which is usually the class name) for determining ITFK names. Otherwise, you couldn't have more than one relationship to the same object.
[/quote]
Hmm. Isn't it more important to be able to name your models differently to your tables? Especially for single table inheritance, for example. I was expecting the model to map correctly because I've specified a different table name. I would have thought to specify different foreign keys than the table name would be a further modification.

I understand how the foreign keys for relationships can be customised to account for multiple foreign keys to the same model but I think being able to have differing model names is a separate issue.

[quote author="OverZealous" date="1251324145"]
FYI: If you aren't working with advanced relationships (where you need to specify a class name, etc.), you don't need to include the empty array in your $has_one or $has_many properties.[/quote]
Thanks yeah I just wanted to keep them all the same.