• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
DMZ 1.7.1 (DataMapper OverZealous Edition)

!! IMPORTANT INFORMATION !! - Please Read This Post

DataMapper is no longer being maintained by Phil DeJarnett (a.k.a. OverZealous)

Click Here for the New Official DMZ Documentation Pages

DataMapper OverZealous Edition 1.7.1

Quote:[strike]Download the Latest Version Here[/strike] (No Longer Current!)

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.)

DataMapper (DM) is an Object-Relational Mapper that builds on ActiveRecord. Data is loaded from database tables into objects, and relationships can be managed through simple, easy-to-read functions.

DataMapper OverZealous Edition (DMZ) adds several important features to DM, enhancing it's usage, usually without requiring any code changes.

To install DMZ over DataMapper, the (fairly simple) upgrade process is described here.

DMZ offers these features:
• Everything is an object!
• Easy to setup, easy to use.
• Custom Validation on object properties.
• Lazy Loading (related objects are only loaded upon access).
• Relations and their integrity are automatically managed for you.
• One to One, One to Many, and Many to Many relations fully supported.
• Select data in the style of Active Record (with or without Method Chaining).

You can learn much more from the manual.


Version 1.7.1:
• Various bug fixes
• New method for seeing if two objects are already related
• All extensions have been updated to use or accept get_iterated
• Please see the change log for details.

Version 1.7.0:

This is a major update to DMZ!

Not only does it include these fantastic new features:
Automatic Localization
• Amazingly easy Paged Queries
• New methods for streaming query results
• PHPDoc documentation has been added for almost every magic method, which can be used for code-hints in an IDE
• A brand-new extension for finding the row of a given object or id
• And a whole lot more features.

But this version includes a staggering number of small performance improvements than, when added up, can reduce page processing time by as much as 50% (even on simple pages!), and reduce memory overhead by nearly as much, especially when combined the new get_iterated method!

There also have been a variety of bug fixes, and tweaks throughout the code base.

Make sure to check out the changelog — you won't want to skip this update!

If you are upgrading from RC1 or RC2: Please see this post


Older Discussions: Version 1.6.2, Version 1.5.4, Version 1.5.3 and older.

Thanks goes to stensi, for providing such an amazing code base to work on.

For those wondering:
I forgot to update the included extensions to use the new *iterated methods. If you are using an extension (such as the array extension's all_to_array), you will still need to use the normal get method.

I plan on remedying this in the next point release.

Haven't tried this yet but will give it a shot. Looks pretty interesting, thanks Smile


I was really waiting for this one to come out !!!!!

Thanks a lot Phil ! I am your #1 fan in the entire world !!!

I will update my code right now !!!!!!!

And, if I find any bug, I will tell you !

Btw, I was trying your program zestyjobs.com ! It is pretty awesome ! I loved what you did with dojo to make that amazing UI !

It have given me some inspiration to change a lot in the UI I am developing for my programs! I am using jQuery... I think that jQuery is easier and I can achieve the results I want with it.

Btw, if you want help translating Zesty Jobs to portuguese you can count with me!

[quote author="PoetaWD" date="1268715281"]
I was really waiting for this one to come out !!!!!
So was I! :lol:
Amazingly, I already have another new feature written (see the 1.6.2 thread). :-P

Quote:Btw, I was trying your program zestyjobs.com ! It is pretty awesome ! I loved what you did with dojo to make that amazing UI !

Thanks, I really appreciate the feedback. I'm sitting on an important performance update to ZJ (not just DMZ, but also major updates to the JS libraries) that will make it even better.

Quote:It have given me some inspiration to change a lot in the UI I am developing for my programs! I am using jQuery... I think that jQuery is easier and I can achieve the results I want with it.
I did a lot of research before choosing Dojo. I had several specific requirements:
1) I really wanted an "infinite" scrolling, sortable list. Dojo was one of the few frameworks that had one at all, and the Dojo DataGrid is quite advanced.
2) I wanted a rich collection of already-built widgets, and, boy does Dojo have that!
3) It also needed to provide a foundation for advanced AJAX interaction. Dojo not only handles XHR wrapping, but it provides automatic form submission via AJAX, and a slick system for querying data from the server in a consistent manner.

Dojo's huge widget library is a great foundation, but it can be quite hefty. Of course, ZestyJobs has dynamic trees, tables, modal dialogs, complex forms including suggestion boxes, sliders, and self-validating fields all loaded right away. It adds up pretty quick.

My current dev version has this awesome feature that uses localStorage to cache all of the JS code - even if the browser's cache is cleared. With that, the second time you load the page takes ~1s, and only has to download ~40Kb. It's pretty cool. (It even intelligently handles software upgrades, replacing just the files necessary.)

I like both jQuery and Prototype. I've used both in the past. I've even played with mootools. When I started ZestyJobs (it's been about 18 months now), the JS framework environment was really different. Even now, I don't think any JS framework has the diversity of Dojo's.

Sadly, they actually had better documentation in the past, but they've been restructuring lately, and they current API docs and manual is lacking. I think it would be very difficult to start using Dojo at this moment in time.

Quote:Btw, if you want help translating Zesty Jobs to portuguese you can count with me!

Thanks. If I decide to support multiple languages, I'll keep that in mind. Currently, the UI is poorly broken up between the JS and the server-side PHP, so handling translations would be very difficult. It's on my list, but currently a low priority.

OK, enough talking about my own projects... :-)

I must say that I really like your work ! And your arguments about DOJO are so strong that I am going to try it ! I might give it a try this weekend !

Have you heard of ExtJS ?

They have awesome features, the forum has A LOT of widgets and the ajax implementation is very easy !

The docs are awesome too !


Thank you very much Phil ! You work is awesome and very inspiring! I wish you lucky with Zesty !

I've definitely heard of ExtJS. I believe it was still fairly young when I started development on Zesty, but either way, I have not used it. (I just checked it out. It looks pretty slick!)

I truly recommend that you find the JS library that matches your needs, the time constraints of your project, and the size and scope of your project. A library like Dojo has a fairly steep learning curve, especially as you start developing your own widgets. You can see how complex Zesty is, and I have great plans for it still. (Up next is printing, followed by simple invoice management.)

Anyway, best of luck deciding.

I just realized, I never made any notes for anyone using 1.7.0-RC1 or 2:

If you are using DMZ RC1 or RC2, you will need to modify these files:
» libraries/datamapper.php - Replace
» config/datamapper.php - Update for localization, see upgrade notes
» helpers/inflector_helepr.php - Replace
Also, if you have a local copy of the manual, make sure you replace it.

Great library once again, I hate coming here because I've found something broken or not working as expected - sorry in advance! (This error occurs with 1.6.* as well.)

Here's my problem. DMZ is looking for a join table where there isn't one and doesn't need to be one.

Here are two related models, the first having a 0*M relationship with the second.

class Pe_style extends DataMapper {

    var $prefix = 'projectexposure_';
    var $table = 'styles';
    var $has_many = array('pe_project_profile','pe_substyle','pe_roomtype');
    function __construct($id = NULL)


class Pe_substyle extends DataMapper {

    var $prefix = 'projectexposure_';
    var $table = 'substyles';
    var $has_many = array('pe_project_profile');
    var $has_one = array('pe_style');
    function __construct($id = NULL)

I'm setting custom table names and prefixes for this objects. This is necessary because the objects are coming from a database which is shared between two applications. I'm using a different prefix for each app, 'tdb_' for this one and 'projectexposure_' for the other, but there are some instances (like this) in which I need to work with objects that are native to the other app, so I'm setting the prefixes in the class declarations of the models for these objects.

'Pe_style' is the model name for a DB table 'projectexposure_styles', and 'Pe_substyle' is named by the same convention. The Pe_substyle table contains a column named 'style_id' to store the relationship. So far, so good, and this works fine in the second app in which the global table prefix is set to 'projectexposure_' and the models are named as per the tables (not needing a custom $table var).

The problem occurs when I do something like this:

$substyle = new Pe_substyle();

foreach ($substyle as $option)
    $substyle_options[$option->id] = $option->pe_style->name." > ".$option->name;

I get this error:

Quote:A Database Error Occurred

Error Number: 1146

Table 'tdbv2.tdb_join_styles_substyles' doesn't exist

SELECT `projectexposure_styles`.* FROM (`projectexposure_styles`) LEFT OUTER JOIN `tdb_join_styles_substyles` tdb_join_styles_substyles ON `projectexposure_styles`.`id` = `tdb_join_styles_substyles`.`pe_style_id` WHERE `tdb_join_styles_substyles`.`pe_substyle_id` = 1

Why is DMZ looking for a join table in a one-many relationship where an in-table FK exists?

I can get around it by creating the related object separately and fetching the instance with a where clause on the FK, but it's not the designed behaviour AFAIK.

Or maybe there are restrictions I wasn't aware of?

Thanks in advance and keep up the good work.

It's not a bug in DMZ, I'm certain. You've most likely got something configured wrong.

First, it looks like a table prefix being added by CodeIgniter. You can't use CI's prefixes with DMZ - DMZ has it's own prefix management.

Second, the only reason DMZ looks for a join table is if it can't find an ITFK. It only looks for ITFK's on has_one joins (obviously), and the ITFK must be named {relationship_key}_id on the table for the model with the has_one.

The only ITFK I see in your models would be projectexposure_substyles.pe_style_id. If the field is not named exactly that, it won't work.

You might be getting tripped up because your classes have model names that don't match up with the table names.

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

Users browsing this thread:
1 Guest(s)

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2017 MyBB Group.