Thread

——————————————————————————————————————————————————
!! 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

Download the Latest Version Here (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 😊

YEEEEEEEESSSSSSSSSSSSSSSSSSSSS!!!!!!!!

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!

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

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.

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.

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 !

Well…

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:

application/
  »  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) 
    {
        parent::__construct($id);
    }

}

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) 
    {
        parent::__construct($id);
    }
}

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();
$substyle->get();

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

I get this error:

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.

@rideearthtom
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.

I just updated my app to DMZ 1.7.0 and ran into a fatal error.  I’m not sure if this is a bug or not.

I added a block of code to my DMZ models to auto-load dependent models in the constructor, something like:

# make sure dependent classes are loaded
foreach (array('has_many', 'has_one') as $type)
    {
    foreach ($this->{$type} as $model => $properties)
        {
        $class = $properties['class'];
        if (! class_exists($class))
            {
            $this->CI->load->model($class);
            }
        }
    }

It broke with a

Fatal error: Uncaught exception ‘Exception’ with message ‘Unable to call the method “_assign_libraries” on the class Rem4_property_file’

message when trying to load a dependent model in the constructor using the code above.  I was able to work around the error by changing the _assign_libraries() function definition in datamapper.php.  On line 6011, I changed

protected function _assign_libraries()

to

function _assign_libraries()

and the problem disappeared.  Do you have any idea what happened here?  Did I do something wrong?

@Jack Scott

Well, you are calling _assign_libraries in your own code somewhere, apparently the Rem4_property_file.  😊

That function is only accessed by DMZ internally.  That’s why it has been made protected.  None of the methods that start with an underscore are publicly-accessible (and they never have been).

Search your code for that function.  It shouldn’t be used outside the DMZ source.  You probably should just remove that method call altogether, where-ever you find it.  There are actually quite a few methods that have been removed from public access.

This was documented in the upgrade instructions.

Edit:
I want to clarify the sentence above: I mean that none of the underscore methods have been documented and supported for use outside of the core library.  In other words, they aren’t part of the DMZ API, so they shouldn’t be called directly.

Technically, they have been “public” before now, but that’s because I only just recently decided to add visibility modifiers to the methods and properties.

@rideearthtom
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.

Thanks for the reply Phil.

There are no CI prefixes set up in my app, only the DMZ ones are configured, and in the above models they are overridden by ‘projectexposure_’ as shown in the code I posted. For this app the DMZ config’d prefixes are are ‘tdb_’ and ‘tdb_join’ (hence the generated SQL).

The way I understood your documentation was that it’s possible to hardcode the table names into each model’s class in order to fix discrepancies, but that this should work for any arbitrary table renaming.

Looking again at the error, it seems that DMZ is looking for a FK column name that matches the model name, not the table name. I.e., in the ‘Pe_substyle’ model, it’s looking for ‘pe_style_id’ to make the join. But the ‘Pe_style’ model specifies that the table name is ‘styles’, not ‘pe_styles’.

The manual reads as follows:

Joining tables must have a specially name id field for each of the tables it is joining, named as the singular of the table name, followed by an underscore (_) and the word id. For example, the joining id field name for table users would be user_id. The joining id field name for table countries would be country_id. This same column name could be used for in-table foreign keys

So unless I missed something fundamental regarding the overriding capabilities of var $table, it looks like there’s a discrepancy between the documented behaviour and the actual behaviour. It’s funny that I didn’t notice this until this week as I’ve been working on this system with CI and DMZ for several months. Hope that I’m wrong and that the problem lies elsewhere.

Like I said, not too many real-life worries as I can always create the related object with a where clause on the FK column.

The fundamental problem is really this:

I have a database with several sets of prefixed tables, one for each of many applications. There’s a central app which has it’s own prefix and set of models, but it also needs to work with data from all other apps. I thought it would be as simple as creating more models and overriding the prefixes, but I ran into a problem when I realised that two apps would have different objects with the same name. No problem when designing the db as the prefixes would be different, but in the central app (which works with all the data) I’d end up with multiple models of the same name with different $prefix overrides, which is obviously impossible. So my workaround was to put another prefix on the model name for differentiation (pe_) and override the table name. Maybe there’s a more elegant solution…?

Great! I’ll upload my project with that new version and see if it works smoothly. Great job! Can’t wait to test it.

Looking again at the error, it seems that DMZ is looking for a FK column name that matches the model name, not the table name. I.e., in the ‘Pe_substyle’ model, it’s looking for ‘pe_style_id’ to make the join. But the ‘Pe_style’ model specifies that the table name is ‘styles’, not ‘pe_styles’.

It is (slightly) incorrectly documented.  (A lot of the documentation is a mix of old DataMapper and new DMZ, so some of it isn’t perfect.)

DMZ uses the $table->model field when generating the ITFK name.  The biggest reason for the difference in the docs is that $table is supposed to be the plural form of the model.  The real purpose of the override is for table names with unusual pluralization.

This is the exact quote on tables from the manual:

Normal tables must be named the lowercase, pluralised version of the object name. So for a user object of User, the table would be named users. For Country, it would be countries. (For odd pluralizations, you may need to hard code the $table or $model fields.)

So, it’s not intended that you would have arbitrary table names.  However, it should work in your case, just rename the ITFK column correctly.

It’s not really a bug, just that you are using the application a bit outside it’s intended design.