CodeIgniter Forums
[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - Printable Version

+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived Libraries & Helpers (https://forum.codeigniter.com/forumdisplay.php?fid=22)
+--- Thread: [Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) (/showthread.php?tid=18196)



[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 08-27-2009

[eluser]OverZealous[/eluser]
[quote author="Mirage" date="1251419600"]Suggestions?[/quote]
Why don't you simply replace node with {$node->table}. Then you don't have to add it to the FROM list. You can also use more of the DMZ functions this way:

Code:
function get_children($node) {
        // get children by getting descendants with count and limit that to 1
        // De-reference some vars for readability
        $lcol = $this->options['left_colname'];
        $rcol = $this->options['right_colname'];

        // only add selections if not overridden
        if(empty($node->db->ar_select))
        {
            $node->select('*');
        }
        else
        {
            // ensure these are selected
            $node->select("id, $lcol, $rcol");
        }
        // DMZ won't add the table name to expressions with parentheses
        $node->select('(COUNT(parent.id)-1) as tree_depth');

        // Isolate the dependants of the parent which are 1 level away
        $node->db->from("{$node->table} as parent");
        
        // Only descendants, parent node not included
        $node->where("{$lcol} >", "parent.{$lcol}", FALSE);
        $node->where("{$lcol} <", "parent.{$rcol}", FALSE);
      
        // Only for the parents part of the tree  
        $node->where("{$lcol} >", $node->$lcol);
        $node->where("{$rcol} <", $node->$rcol);
                
        $node->group_by("id");
        $node->having("tree_depth =",1); // DMZ won't add the table name to unknown columns
        $node->order_by($lcol);
        
        // Run query
        $node->get();
   }

This also allows someone to add query information to the result, such as writing code like this:
Code:
// filter on 'foo'
$items->like('foo', 'bar')->get_children($parent_item);
// limit column selection
$items->select('foo')->get_children($parent_item);

This now works because the main table name is still correct.


[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 08-27-2009

[eluser]Mirage[/eluser]
Quote:Why don't you simply replace node with {$node->table}. Then you don't have to add it to the FROM list.

I came to that conclusion as well. But thanks for confirming it. Also - thanks for the additional info. I'm sure I'll get the hang of it as I progress.

Cheers!
Juergen


[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 08-27-2009

[eluser]Mirage[/eluser]
I found a bug. Not sure if it's DMZ or AR. Queries can get screwed in NON-ESCAPE mode:

This code:
Code:
$node->where("{$lcol} > ", "parent.{$lcol}", FALSE);
$node->where("{$lcol} < ", "parent.{$rcol}", FALSE);
$node->where("{$lcol} >", $node->$lcol);
$node->where("{$rcol} <", $node->$rcol);

Will produce this SQL (bad):
Code:
WHERE apn_pages.lft >parent.lft
AND apn_pages.lft  '9'
AND `apn_pages`.`rgt` < '12'

With this adjustment (adding a space before parent in the unescaped clauses):
Code:
$node->where("{$lcol} > ", " parent.{$lcol}", FALSE);
$node->where("{$lcol} < ", " parent.{$rcol}", FALSE);
$node->where("{$lcol} >", $node->$lcol);
$node->where("{$rcol} <", $node->$rcol);

will correctly produce:
Code:
WHERE apn_pages.lft > parent.lft
AND apn_pages.lft < parent.rgt
AND `apn_pages`.`lft` > '9'
AND `apn_pages`.`rgt` < '12'

Cheers,
-m


[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 08-27-2009

[eluser]OverZealous[/eluser]
It's in AR, but it's not a bug, per se. When you say "don't escape", AR takes that to mean "don't modify, at all", so it isn't adding a space. (DMZ just passes the info to the AR methods.)

That being said, I don't know why apn_pages.lft >parent.lft should fail. Maybe it's a MySQL bug? It works under Postgres. :-\


[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 08-27-2009

[eluser]Mirage[/eluser]
Phil,

The sql output is from last_query(), so I don't think it's got anything to do with mysql. You're right the space doesn't and shouldn't matter, but the sql generated by AR is just cut and jumbled.

-m


[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 08-27-2009

[eluser]Mirage[/eluser]
Another Extension question:

Does each model receive it's own instance of an extension or is there only a single instance of an extension for all models that use it (or globally configured).

Thanks,
-m


[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 08-27-2009

[eluser]OverZealous[/eluser]
[quote author="Mirage" date="1251439681"][...] the sql generated by AR is just cut and jumbled.[/quote]

Oh, my mistake. I was reading it wrong. I think I found the bug, and it was in DMZ. I was trimming the field name to determine if I should add the table name, but I was using trim, when I should have been using ltrim. I think this is what was breaking it.

The reason this only showed up under non-escape mode is that AR was adding back the space that DMZ was eating. :-)

I fixed it in the source, but if you want to try it, test out the attached version.

edit: fixed typo above, meant to say in DMZ


[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 08-27-2009

[eluser]Mirage[/eluser]
Yep, that fixes it. Though if I'm reading you correctly it's still broken in AR?


[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 08-27-2009

[eluser]OverZealous[/eluser]
Edit: corrected that it was 1.5.1 that has the new local/global extension settings.

[quote author="Mirage" date="1251440468"]Does each model receive it's own instance of an extension or is there only a single instance of an extension for all models that use it (or globally configured).[/quote]

In 1.5.1, there is one instance if created globally, and another, different instance for each type of model if created locally.

So you could have a globally created json, a different json on Users, and a third json on Groups. Not that you would ever want to do that.

Each individual instantiated class does not get its own copy. This would be inefficient, I think, since someone could load up large dataset and end up with 100s of extra objects in memory that aren't even being used.

It doesn't say it in the docs, but extensions are intended to be mostly stateless, except for the initial configuration.

If you need to track a per-object value, I recommend adding properties to the model directly.

For example:
Code:
// in extension
function something_cool($object, $param) {
    // store the current time for tracking
    $object->_my_extension_start_time = time();
    ...

Use something highly unique for the value so it won't get in the way.

Quote:Yep, that fixes it. Though if I’m reading you correctly it’s still broken in AR?
See my edit, I made a typo. The bug was only in DMZ.

PS: You said the docs don't mention the prefix earlier, I'm pretty sure there's a huge yellow box on this page that does just that, or am I misunderstanding what you wrote?


[Deprecated] DMZ 1.5.3 (DataMapper OverZealous Edition) - El Forum - 08-27-2009

[eluser]Mirage[/eluser]
Phil,

I agree it would be in-efficient and was just wondering about how it's handled. I'm tempted to do some caching of vars in my extensions. If extensions aren't separate instances then I just need to account for that.

Thanks for the clarification.

Quote:PS: You said the docs don't mention the prefix earlier, I'm pretty sure there's a huge yellow box on this page that does just that, or am I misunderstanding what you wrote?

Well, since it's a config setting I assumed I'd be able to find it on this page:
http://www.overzealous.com/dmz/pages/config.html but it's not listed. :-)

BTW - thanks for the mentions in your changelog. I'm honored!

Cheers
-m