[Deprecated] DMZ 1.6.2 (DataMapper OverZealous Edition)

1 of 47

Last

OverZealous

Posted: 23 November 2009 11:54 PM

[ Ignore ]

Lab Technician

Total Posts: 1041

Joined 10-08-2008

This is an outdated version. Please see the newer version here.

DataMapper OverZealous Edition 1.6.2

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 NEW!
(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 and more over the original DataMapper:
• In-table foreign keys
• Multiple relationships to the same model
• Better self references
• Add fields from a related model into one query
• Update, view, and query extra columns on join tables
• The ability to generate and use subqueries
• A shareable extension mechanism, including:
• Easy creation of HTML forms,
• Processing posted input,
• Converting to-and-from JSON, CSV, and arrays, and
• Query caching

—————

Version 1.6.2:
NOTE: 1.6.2 includes a minor bugfixes. There are no changes to the core DMZ library.

If you are upgrading from 1.5.x or earlier, this is a major change. There is a good chance DMZ 1.6 could break existing code.

The major changes in this version revolve around the db object. Previously, a single DataBase object was created for the entire application. Changes to any $object->db would affect all other objects, widgets, and whatevers.

DMZ 1.6 introduces a dynamically created DB object. A new one is created every time a query is needed. There are several important reasons for this:

1. Multiple queries can be built simultaneously. If one large query is being built, and needs the results of a different query, it is safe to build, run, and process a second query, without affecting the original.
2. The multiple query functionality makes it possible to create subqueries using the existing Active Record methods. This is very powerful, as you can build the query on the other object, then easily include it in your main query.
3. Subqueries allow DMZ to calculate and include the number of related objects along-side the main object being queried.
4. While not tested, it should be easier that ever to work with multiple databases simultaneously. (You won’t be able to query across them, but no more hacking to get a different DB for different objects!) See db_params on this page.

The dynamic DB can be disabled, but all of the above will no longer work.

Besides this, DMZ 1.6 includes several other new features:
• SQL Functions and expressions can be built using AR-like methods, as well as used in SELECT and query statements.
• You can get the text of a query without running it using get_sql.
• There is a new virtual validation rule, always_validate, that can be used to override the default behavior of ignoring non-required empty fields.

—————

Older Discussions: Version 1.5.4, Version 1.5.3 and older.

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

Signature

Phil DeJarnett
OverZealous Creations, LLC

Profile

OverZealous

Posted: 24 November 2009 12:11 AM

[ Ignore ] [ # 1 ]

Lab Technician

Total Posts: 1041

Joined 10-08-2008

I’m releasing DMZ 1.6.0 now. Since this is a long holiday weekend here in the United States, I will not be able to provide help right away if you come across any bugs.

However, please feel free to give it a once-over, take it for a test drive, and all that. If you find any problems, post a message on this forum. I’ll try to look them over next week.

Also, I’ve been very busy lately (these updates were ready in mid-October!), so I might have forgotten to include requests from the previous forum. If so, leave a note here, and I’ll try to remember next time.

Signature

Phil DeJarnett
OverZealous Creations, LLC

Profile

Mirage

Posted: 24 November 2009 01:26 AM

[ Ignore ] [ # 2 ]

Lab Assistant

Total Posts: 287

Joined 09-30-2006

Phil, awesome release. I can take advantage of the validation enhancements right away. Looking forward to trying out all of the other cool stuff. Stand by for silly questions.

Have a great holiday!
-m

Signature

sitesquad.net | < insert catchy tagline here />

Profile

The Hamburgler

Posted: 24 November 2009 09:43 AM

[ Ignore ] [ # 3 ]

Summer Student

Total Posts: 30

Joined 06-25-2008

Great work Phil, I’ll be trying out the dynamically created DB object asap.

I’ve had problems with building multiple queries before but just hacked a workaround.

Don’t know why I never considered this solution!

Signature

StuckTogetherWithTape

Profile

OverZealous

Posted: 24 November 2009 12:29 PM

[ Ignore ] [ # 4 ]

Lab Technician

Total Posts: 1041

Joined 10-08-2008

The Hamburgler - 24 November 2009 02:43 PM

I’ve had problems with building multiple queries before but just hacked a workaround.

Don’t know why I never considered this solution!

That’s funny, ‘cause that’s what I was thinking when I realized I could so easily create new DB objects! It’s incredibly clean, and once I realized how much I could get away with (such as the sub query stuff), I was quite pleased with the result.

Now, to eventually walk through my code base and rip out all the hard-coded stuff.

Signature

Phil DeJarnett
OverZealous Creations, LLC

Profile

The Hamburgler

Posted: 24 November 2009 04:27 PM

[ Ignore ] [ # 5 ]

Summer Student

Total Posts: 30

Joined 06-25-2008

OverZealous - 24 November 2009 05:29 PM
The Hamburgler - 24 November 2009 02:43 PM

I’ve had problems with building multiple queries before but just hacked a workaround.

Don’t know why I never considered this solution!

That’s funny, ‘cause that’s what I was thinking when I realized I could so easily create new DB objects! It’s incredibly clean, and once I realized how much I could get away with (such as the sub query stuff), I was quite pleased with the result.

Now, to eventually walk through my code base and rip out all the hard-coded stuff.

For some reason I had it in my head that the CI database object was static and so this approach wouldn’t work…

Signature

StuckTogetherWithTape

Profile

monkeyhouse

Posted: 25 November 2009 12:41 PM

[ Ignore ] [ # 6 ]

Summer Student

Total Posts: 5

Joined 06-17-2008

New features are awesome.

I did have a small issue on a fresh install of CI 1.7.2 and DMZ 1.6.0.

The datamapper.php config file has this line.


$config['db_params'] = NULL;

For some reason with the line set that way I got an error that said. “You have not selected a database type to connect to.”

If I set the line as follows, it fixed the problem and everything works as it did before.


$config['db_params'] = '';

Hopefully this helps anyone else that might have the same issue.

Profile

thompanilla

Posted: 30 November 2009 01:54 PM

[ Ignore ] [ # 7 ]

Summer Student

Total Posts: 5

Joined 11-17-2009

monkeyhouse! thank you! i thought i was going crazy!

Profile

OverZealous

Posted: 30 November 2009 02:04 PM

[ Ignore ] [ # 8 ]

Lab Technician

Total Posts: 1041

Joined 10-08-2008

@monkeyhouse
Thanks for finding that. I’m not sure why it has never given me an error, but it is a definite bug (even when looking through the CI database loading source source).

I’ll get a minor bugfix release put out soon.

——————————

Update:
OK, the fix is out. I also updated the manual to reflect this change.

It turns out the DataMapper object had the correct default (’‘), but the config had the incorrect one (NULL). That’s why I didn’t see the error.

As mentioned above, if you get this error, simply change the default value of db_params to ‘’ (empty string). It’s not necessary to download the new version.

Signature

Phil DeJarnett
OverZealous Creations, LLC

Profile

Jamie Rumbelow

Posted: 30 November 2009 03:36 PM

[ Ignore ] [ # 9 ]

Research Assistant

Total Posts: 739

Joined 02-24-2008

You’ve done a great job with this since the beginning Phil, and with every new release it keeps getting better! It’s an excellent library and I’m very, very impressed. How does DMZ handle polymorphic associations? Can you give me a quick primer on how (if) it works under the hood?

Jamie

Signature

Sparkplugs - Intuitive add-ons for ExpressionEngine and MojoMotor
—-
Taggable - ExpressionEngine Tagging Module
MojoBlog 2 - MojoMotor Blog Module/Add-on
—-
Freelance Web Developer - @jamierumbelow - http://jamieonsoftware.com

Profile

OverZealous

Posted: 30 November 2009 04:01 PM

[ Ignore ] [ # 10 ]

Lab Technician

Total Posts: 1041

Joined 10-08-2008

@Jamie

The short answer is, it doesn’t. There is no inherent support for extending classes (yet).

That being said, you can back multiple models with a single table. It just requires a bit of work, including overriding the save and get methods to set or clear type flags.

For example, you might have a flag called is_manager, and the Employee class clears the flag when saving, and adds a where(‘is_manager’, FALSE) when getting, and the Manager class does the opposite.

Also, all relationships have to be mapped individually for each class if you are using this technique. You will lose the ability (in the example above) to query all Employees and include all Managers at the same time.

There is a way around some of that last piece, using the advanced relationships. In my app, I have two objects, Jobs and Service Calls. A Service Call is really a special case Job. Jobs is normal, except it clears is_servicecall for saving and getting.

Now, say I have an model called Task. In Job, it is related like this:

$has_many = array('task');

function get($limit = '', $offset = '') {
    $this->where('is_servicecall', FALSE);
    parent::get($limit, $offset);
}

// important: must allow for getting any type
function get_any($limit = '', $offset = '') {
    parent::get($limit, $offset);
} 

In Service Call:

var $model = 'servicecall';
var $table = 'jobs';

var $has_many = array(
    'task' => array( 'join_self_as' => 'job' );
);
function get($limit = '', $offset = '') {
    $this->where('is_servicecall', TRUE);
    // notice: calling get_any
    parent::get_any($limit, $offset);
} 

In Task:

var $has_one = array(
    'job',
    'servicecall' => array('join_other_as' => 'job')
); 

Now servicecall and job are both related using the same database tables, and can be queried together using get_any.

You can also automate configuring the ServiceCall model, by having a constructor like this:

static $_sc_did_config = FALSE;
function __construct($id = NULL) {
    // only configure service call properties once (it's cached for all other copies)
    if(!self::$_sc_did_config) {
        // Fix relationships
        foreach(array('has_one', 'has_many') as $f) {
            $new = array();
            foreach($this->{$f} as $field_name) {
                $new[$field_name] = array('join_self_as' => 'job');
            }
            $this->{$f} = $new;
        }
        
        self::$_sc_did_config = TRUE;
    }

    parent::__construct($id);
} 

—————

In summary: It is a lot of work to maintain, and I have yet to see a great reason to use polymorphism in a DMZ-backed app. I highly recommend avoiding it if possible. Personally, I wish I had just gone with tracking the information via the flag, and skipping the polymorphic objects, but it would be a lot of work to change the current design in my app.

Signature

Phil DeJarnett
OverZealous Creations, LLC

Profile

1 of 47

Last

‹‹ CI Session library improvement Open Source Codeigniter Only Forum Project ››

Username		Remember Me?
Password		forgot password?