Thread

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.

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

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

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!

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

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…  :down:

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.

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

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

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

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

I am really enjoying the DMZ library thus far. There is a bit of a learning curve, but it’s really worth it.

There’s a pretty solid library in CI already for dealing with file uploads, but it’s not clear to me if it’s possible to use it with DMZ’s built-in form generation and handling, which I’d like to use to handle all the metadata associated with an uploaded file.

Would I call the do_upload method as a validation function? If anybody could provide an example of how it might be used or comment on if it’s possible or advisable, that would be great.

For Subquery function

Does it support multi time subquery for same data object?

For Subquery function

Does it support multi time subquery for same data object?

I’m not sure if this is what you are asking, so correct me if I’m wrong.

The subquery functionality allows you to create multiple subqueries on different Objects.  It doesn’t matter if they have the same Class.

For example, this would work:

// You can now interleave multiple queries
$user1 = new User();
$user2 = new User();

$user1->where('name', 'Fred');
$user2->where('name', 'Bob');

$user1->get();
$user2->get();

This, however, will not work, because there is only one query object:

// WILL NOT RETURN ANYTHING!!!
$user1 = new User();

$user1->where('name', 'Fred');
$user1->where('name', 'Bob');

$user1->get();

(I know those aren’t subqueries.)

And, of course, you can use different Classes without an issue.  What this means is that you should be able to perform subqueries with self-related objects.

Hi Phil, what do you think of an RSS feed to subscribe for the changelog / version updates? That’d be cool! (or did I miss an existing one?)