Thread

Make 100% sure you are doing this: count($p->all) and not this: count($p).  I just tested it to be sure, and the latter always returns 1.

I’ve got helpers all over, and have never seen anything like this.  It just doesn’t make sense, since $p->all is a normal PHP array, and count is an internal PHP function.

Is the Datamapper library getting loaded correctly before it is used in your helper?  Are you sure that $p is a valid object?

Again, I just tested it, using almost exactly the same code.  Works perfectly for me.

Yeah, I triple checked when I saw your first reply and panicked that I did something really dumb, haha.

I don’t see why it wouldn’t work either, that’s why I’m kind of stumped…

I give up for now, I’ll look over it all with fresh eyes tomorrow and I’m sure I’ll see some obvious logic problem or something…

Thanks for the quick replies as always!

Hi,
Here comes the french translation. Keep the good job !

In fact I have not used DMZ since version 1.4 (no PHP project at the moment) and I am a bit afraid of all the new features, I am afraid I will find DMZ not as easy to use as it used to be. Don’t you think that the main advantage of DMZ over others ORM is is that every thing is straightforward ? Here is my point : the more you add features, the more complexe DMZ will be, up to a point it will look like Doctrine (for example). But Doctrine has a better “support” (the lead developper is paid by a company) and a “communauty”, so maybe DMZ will not be as attractive for CI users.

Just my thought 😊 I would like to hear from you about the future of DMZ, I mean what it aims to be, its “philosophy”.

(Sorry for my weird vocabulary or sentences, I am not fluent in English, but I try !)

————————————————————————————————

<?php

$lang[‘alpha_dash_dot’]      = ‘Le champ %s ne doit contenir que des caractères alphanumériques, des tirets bas ou haut, et des points.’;
$lang[‘alpha_slash_dot’]  = ‘Le champ %s ne doit contenir que des caractères alphanumériques, des tirets bas ou haut, des slashes et des points.’;
$lang[‘min_date’]      = ‘Le champ %s doit etre ultérieur à %s.’;
$lang[‘max_date’]      = ‘Le champ %s doit ëtre antérieur à %s.’;
$lang[‘min_size’]      = ‘Le champ %s doit ëtre supérieur à %s’;
$lang[‘max_size’]      = ‘Le champ %s doit être inférieur à %s.’;

$lang[‘transaction’]      = ‘%s a échoué à %s.’;
$lang[‘unique’]      = ‘La valeur du champ %s renseignée est déjà prise.’;
$lang[‘unique_pair’]      = ‘La combinaison des champs %s et %s est déjà prise.’;
$lang[‘valid_date’]      = ‘Le champ %s doit contenir une date valide.’;
$lang[‘valid_date_group’]  = ‘Les champs %2$s doivent contenir une date valide.’;
$lang[‘valid_match’]      = ‘La valeur du champ %s doit ëtre %s.’;

$lang[‘related_required’]  = ‘Une relation %s est requise.’;
$lang[‘related_min_size’]  = ‘La relation %s doit être supérieure à %s.’;
$lang[‘related_max_size’]  = ‘La relation %s doit être inférieure à %s.’;

$lang[‘dm_save_rel_failed’]  = ‘La relation %s n\‘est pas définie correctement.’;
$lang[‘dm_save_rel_nothis’]  = ‘Impossible de sauvegarde la relation %s : cet objet n\‘est pas sauvegardé.’;
$lang[‘dm_save_rel_noobj’]  = ‘Impossible de sauvegarde la relation %s. L\‘objet en relation n\‘est pas sauvegardé.’;

/* End of file datamapper_lang.php */

/* Location: ./application/language/english/datamapper_lang.php */

@jpi

I’m not sure what the issue is.  DMZ has not truly eliminated or significantly changed any features almost since I started extending DataMapper.  Almost all of the features I have added are about solving real problems.  Extensions allow anyone to add certain types of features in a clean, supported manner, without touching the source code.

If you want to use DMZ the way it was in the past, you still can.  If you want to use the new features, they are there to make life simpler.

I’ve never used Doctrine, however, if it is anything like most “full” ORMs, it probably requires a significant amount of time to learn, configure, and integrate with CodeIgniter.  If you are planning on developing a large PHP project, it would be worth it.  If you are just building a small, one-off website, it might not be.  Again, I don’t know anything about Doctrine, and I am not speaking about Doctrine specifically!  Doctrine may be a lovely ORM.  I just am already using DMZ, and swapping ORMs is effectively impossible without starting over.

DMZ is still targeted at simpler websites, where the main goal is to integrate a database with objects.

I understand that Doctrine might be better supported.  Heck, I never intended to support DataMapper in the first place.  But the original DM stagnated, and I needed specific features.  I add in the features I use, and try to support requested features.  I release these changes so that others can benefit.  I do my best to keep the manual up-to-date, and relevant, but there might be mistakes.  I’ve also had semi-regular releases about once-a-month.

Beyond that, I make no promises.  😊

Hey, I did some little upgrades to DataMapper.
Just added the possibility to model has after_save and before_save methods. How works ? very simple:

class Model extends DataMapper
{

$after_save = "call_function_after_save";
$before_save = array("func1", "func2");

}

and that call a internal function on the Model. Very simple.

The version can be founded here: http://www.leonardopereira.com/datamapper.phps

Here is a translation of DMZ to brazilian-portuguese: http://www.leonardopereira.com/datamapper_lang.phps

And thank you soo much for this incredible library !

Cya.

——-
Leonardo Pereira
Cya

Thanks, I added the pt_BR language to the source repository.

Eventually I’ll be adding methods that can be used to hook into the main methods (save, delete, etc.) for use in extensions, which will be better for upgrades and so forth.

Validation can be used to modify fields just before a save, and that is the recommended method in most cases of handling before save code.

However, if you need after save or other functionality, it would be easier to do this in a subclass:

class User extends DataMapper
{
    function save($object = '', $related_field = '')
    {
        // handle before save stuff here
        // ex: $this->do_before_save($ret);
        
        $ret = parent::save($object, $related_field);
        
        // handle after save stuff
        // ex: $this->do_after_save($ret);

        return $ret;
    }
}

Then you don’t have to modify the source to DMZ, nor do you have to worry too much about upgrades.

Thanks ! That’s sure a better solution. =)

Is it possible to add a relation to an object from inside one of its custom validation rules?

Specifically, I’m taking some user-provided content (a tweet), parsing through it looking for hashtags and URLs, shortening said URLs, checking to see if they exist in the database already, and saving them as related objects. It’s all preparatory logic because it can alter the content of the tweet (shortened URLs, eliminating duplicate hashtags if necessary, all to get it under 140 characters) so the logical place to do it is in a validation method.

Currently I’m doing it outside of the object, but it would be really sweet for my model to be totally self-contained to avoid repeating a bunch of logic.

I don’t recommend performing any logic like that inside a validation rule.  You could easily get caught in an infinite loop.

However, why don’t you do something like this:

class Whatever extends DataMapper {
    ...
    function save($object = '', $related_field = '') {
        // perform logic here
        // if necessary, add a new object to the $object array
        if(is_array($object)) {
            $object[] = $new_object;
        } else if(!empty($object)) {
            $object = array($object, $new_object);
        } else {
            $object = $new_object;
        }
        return parent::save($object, $related_field);
    }
}

The only catch is you always need to save it from the Whatever object, but that should be a rather easy-to-enforce situation.

Yo all. I’m having some problems with using the include_related_count() function on advanced relationships. It seems to work 100% fine on non advanced relationships. My application is getting a bit complex so I installed a fresh copy of the latest CI (1.7.2) and DMZ (1.6.1) and created an example to show the problem:

SQL:

CREATE TABLE IF NOT EXISTS `owners` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
) ;

CREATE TABLE IF NOT EXISTS `puppies` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `breed` varchar(255) NOT NULL,
  `somethingelse_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ;

Puppy Model:

<?php
class Puppy extends DataMapper
{

    var $has_one = array
    (
      'somethingelse' => array
        (
          'class' => 'owner',
          'other_field' => 'puppy'
        )
    );

    function __construct($id = NULL)
    {
        parent::__construct($id);
    }

}

Owner Model:

<?php

class Owner extends DataMapper
{

    var $has_many = array
    (
      'puppy' => array
        (
          'class' => 'puppy',
          'other_field' => 'somethingelse'
        )
    );

    function __construct($id = NULL)
    {
        parent::__construct($id);
    }
}

And Finally The Controller:

<?php

class Welcome extends Controller
{

    function Welcome()
    {
        parent::Controller();
    }

    function index()
    {

        $owner = new Owner();
        $owner->name = 'John';

        $owner->save();

        $puppy = new Puppy();
        $puppy->breed = 'pomeranian';
        
        $puppy->save(array('somethingelse' => $owner));

        $result = new Owner();
        $result->include_related_count('puppy');
             
        $result->get();


    }
}

When I run that. It gives me the following:

A Database Error Occurred
Error Number: 1064

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '`owners_subquery`.id = `owners`.`id`) AS puppy_count FROM (`owners`)' at line 4

SELECT `owners`.*, (SELECT COUNT(*) AS count FROM (`puppies`) LEFT OUTER JOIN `owners` as somethingelse_owners ON `somethingelse_owners`.`id` = `puppies`.`somethingelse_id` WHERE somethingelse_`owners_subquery`.id = `owners`.`id`) AS puppy_count FROM (`owners`)

If I change the relationships back to simple and use the include_related_count it works completely fine. I had a look through the function in the library, although I think the problem is probably located within another function. I haven’t really had much time to look through it thoroughly.

Anyone else ran into this problem ? If I can’t figure out a fix I might have to use a simple relationship. I was just using an advanced relationship to have an easier to use name instead of the name of the class in my original scenario.

Update: In case you don’t want to read all of the SQL error (I just realised how long it is). The problem is here:

somethingelse_`owners_subquery`.id

Just CTRL+F that part to see the problem. If I could get ‘somethingelse_’ to not be there, that would be awesome :D

@Cro_Crx

Yep, looks like that is a bug.  I’m not sure how I’m going to fix it (or if it is even possible), but I’ll look into it when I get a chance.

Well, that was easy.  Assuming I didn’t make any mistakes, I simply changed the replacement regex for subquery to only replace the tablename if it wasn’t prefixed with _.

Simply enough, and covers the common cases.

Anyway, thanks (very much) to Cro_Crx for providing such a clear test case and making it so easy to track down!

An updated release with this bugfix, the new language files, and other recent bugfixes is being prepped right now.  It should be out in 20 minutes or so.

Ok, the update is out.  Version 1.6.2 contains bug fixes, the new language files, and a variety of minor updates to the manual.

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
  Search the Manual
  (Due to the server’s caching configuration, you may need to forcibly refresh your browser to see the changes in the manual.)

I think I’ve found another bug. There is a problem with default values in validation/get rules. An empty string is being passed instead of a NULL when no param is set. This is stopping default values from being used.

var $validation = array(
    'field1'    => array(
        'get_rules' => array('max_tacos' => 75),
    ),
    'field2'    => array(
        'get_rules' => array('max_tacos'),
    ),
...

function _max_tacos($field, $param=5){
    //field1 $param type is int, value is 75
    //field2 $param type is string, value is ''
}

@12vunion

That’s not a bug - that’s how it is designed.  It mirrors the way validation rules work exactly.

The end result is you cannot have default values on get_rules parameters, or you must explicitly check for the empty string and set the value.

Require At Least

My small contribution to the DMZ community, hope it’s helpful for you.

Example:

Say you have a community website, and besides the regular contact information for a user, you want to have at least something on the user’s profile page so that it’s not a big sea of blankness. So you might create a model that looks like this:

class User extends DataMapper {
    
    var $extensions = array('require_at_least');

    var $validation = array(
        /* Other User validation fields omitted for brevity's sake */
        'about' => array(
            'label' => 'About You',
            'rules' => array('max_length' => 200,'trim')
        ),
        'favorite_quote' => array(
            'label' => 'Favorite Quote',
            'rules' => array('max_length' => 200,'trim')
        ),
        'fondest_memory' => array(
            'label' => 'Your Fondest Memory',
            'rules' => array('max_length' => 200,'trim')
        ),
        'form_completeness' => array(
            'label' => 'Form Completeness',
            'rules' => array(
                'always_validate' // Important step, otherwise the rule won't run
                'require_at_least' => array(
                    'num_required' => 1,
                    'fields' => array(
                        'about',
                        'favorite_quote',
                        'fondest_memory'
                    )
                )
            )
        )
    );
}

Each of the validation elements ‘about’, ‘favorite_quote’, and ‘fondest_memory’ corresponds to a field in the database. But that last element is a non-field validation rule (think “Confirm Password” from the DMZ examples).

Require At Least provides a rule that allows you to require that ‘num_required’ of the ‘fields’ you specify are filled in. If the minimum number is not met, an error will be set. In the case of the example above, the error would read, “You must supply at least one of the fields About You, Favorite Quote, or Fondest Memory.”

Download it here.

I’ll do my best to answer questions about it here if I can, but can’t guarantee it as I’m about three deadlines behind already. 😊