Thread

@Jack Scott
Regarding the autoload method: it’s going to be called anytime a class is requested that hasn’t already been loaded, no matter where that class is called.  (It’s related to the way PHP loads classes.)  Due to the required naming scheme (ie: that every model has to have a unique class name across the entire app, and the file name is the same as the class), it shouldn’t ever cause an issue.  (You cannot have any other classes with the same name as your DMZ models, just like you can’t have any two classes with the same name, anywhere.)

I’m not ready to start worrying about CI 2.0 yet, and I don’t have access to EE.  Feel free to post it, but I’m probably not going to be worrying about it too soon.

I don’t think there is an issue with letting CI load the models, other than if CI loads a model, that model gets instantiated whether or not it is used.  If you let DMZ lazily load the models, then only the models needed for that request get loaded.  I wasn’t going to allow models to be loaded via CodeIgniter, even with the name change, just provide a better error, but I’ll think about it.  (It’s important to realize that DMZ models aren’t truly CodeIgniter models - they don’t share any code with CI’s models, and they work very differently.)

@Mareshal
I think you need to spend some time reading through the General Topics section of the manual.

The manual is fairly complete, if not perfect, and really discusses how DMZ works.

Edit: I was wrong. My bad. Deleted my post

Thanks for the above comments. I’ll continue using my workaround.

I have another situation that I’m unsure how to handle. Basically I want to create a relationship where the PK of the relationship is defined by the ids of three other models. A bit like a join table but with 3 FKs.

To put it into its real world example, I have two models, Project and Location, which have a M*M relationship, using a join table. I have another model, Document, and I want to relate this to the relationship between the Project and the Location. I can’t use a field in the join table as that would only allow for one Document to be related. I’m not sure that it’s a good idea to create another join table that relates Documents to the Project/Location join table. Maybe this is something else that I’ll have to do outside of the DMZ framework?

Hello Phil,

The updated autoload() method is included below.  It uses the loader’s _ci_model_paths property to locate models.  I suspect this is intended to be a private property, and may not work in future versions, but we’ll cross that bridge when we get to it.

public static function autoload($class)
    {
        // Don't attempt to autoload CI_ or MY_ prefixed classes
        if (in_array(substr($class, 0, 3), array('CI_', 'EE_', 'MY_')))
        {
            return;
        }

        // Prepare class
        $class = strtolower($class);

        // Prepare path
        $CI =& get_instance();
        if (isset($CI->load->_ci_model_paths) && is_array($CI->load->_ci_model_paths))
        {
            // use CI loader's model path
            $paths = $CI->load->_ci_model_paths;
        }
        else
        {
            $paths = array(APPPATH);
        }
        
        foreach ($paths as $path)
        {
            // Prepare file
            $file = $path . 'models/' . $class . EXT;
            
            // Check if file exists, require_once if it does
            if (file_exists($file))
            {
                require_once($file);
                break;
            }
        }
        
        // if class not loaded, do a recursive search of APPPATH for the class
        if (! class_exists($class))
        {
            DataMapper::recursive_require_once($class, APPPATH . 'models');
        }
    }

thanks for the great datamapper =)

@Buso
Err, Thanks!  Guess I’m too fast. 😉

I guess you found this page: http://ellislab.com/codeigniter/user-guide/database/connecting.html

@Buso
Err, Thanks!  Guess I’m too fast. 😉

I guess you found this page: http://ellislab.com/codeigniter/user-guide/database/connecting.html

ahahah

nah, its just that i never used it that way (or i lost my memory), AND i was loading it as a model or something, not a library (lol)

thanks again, ill never write a JOIN query again

@Jack Scott
I’ll look into including that with DMZ 1.7.1, since it seems harmless.

@Everyone
Also, I’ll fix the _assign_libraries problem, in some manner.  I think I’m going to have DMZ log a warning, but not print any errors.  You really shouldn’t use CodeIgniter to load your DMZ models, but some might still want to use it that way.

Hope everyone has a great weekend.  I’ll look at rolling up these few bugfixes / changes and getting them out by Monday.  1.7.1 already has a new function (is_related_to), fixes to the examples and extensions that allow them to work with get_iterated, and some minor bugfixes.

If you have any other wishes for 1.7.1, now is the time to let me know! 😉

Other wishes: somehow include selected join fields with the json extension.

Any ideas on the above situation (#33)?

Keep up the good work!

@OverZealous, what’s your guide when adding new features to DMZ? Guide I mean, which other ORM ?

@rideearthtom
You can already do that: just include the “join_<name>” column names when using to_json.  You should always specify the column names, anyway, so you know exactly what is being sent.

As for your question above, check this post for some pointers.  That’s basically the only way to make it work.

@Mareshal
Not sure exactly what you mean.  I don’t build DMZ based on other, existing ORMs.  stensi based his original design on someone who based their design on (I assume) the RoR DataMapper pattern.

I based my changes on adding features that I find useful, or others have requested many times.  I’m not building toward a goal, per se, but rather, building up.  At this point, feature-wise, I’m trying my best to not add more to the base library, as it is already very, very big.  The reason 1.7 included so many new core features is that all but a few of them (namely, the paging functions) required changes in the library itself to work.  And I figured the paging tools were useful enough that I should have them as part of the core.

I guess that I’ve been working with ideas for my own ORM library for a long time.  When I was a Java developer, the big ORM was Hibernate.  But I could never get started, because it felt like you needed a couple hundred XML files to get it working.  So, to keep from writing SQL code, I have to write a ton of XML code.  And still write a ton of Java to glue everything…  Yeah, that’s soooo much better. 😊 (A lot has changed since then, I know.)

Anyway, when I started using DataMapper, I needed certain things (self-relationships, multiple relationships, join table fields, etc).  When stensi was unable to work on DM for a while, I took over (I did discuss this with him some), with DMZ.

Hoepfully that helps explain somewhat.

I didn’t say you build DMZ on other ORMs. But you must implement some methods which are already made in other big projects like doctrine.

@Mareshal
I still don’t understand the question, but the answer is, no, I don’t.  I don’t use Doctrine.  I don’t have it installed.  I use DMZ.  😉

Hi,

I just started using this library and I really like it. I’ve tried doctrine and ignited record and dmz seems to be exactly what i’m looking for. So far it’s been the easiest to use and fastest ORM. Thanks for writing this code.

I am running into a problem with advanced relationships. This is my first codeigniter /dmz app and maybe i’m overlooking something so please bare with me. I’ve read through the user guide and cant seem to find an answer. Also please forgive me if this is the wrong place in the forum to post this question. This is my first post on ci forums.

I have two models, Event and User. Event is related to User in tow ways. Event has_one owner user and has_many subscriber users. User has_many subscribed events and has_many owned_events.

My models are setup like this:

class Event extends DataMapper {
var $has_one = array(
            'owner' => array(
                'class' => 'user',
                'other_field' => 'ownedevent'
                    )        
            );   
        
    var $has_many = array(
            'subscriber' => array(
                'class'=>'user',
                'other_field'=>'subscribedevent'
            )
            );

class User extends DataMapper {
        
    var $has_many = array(        
        'subscribedevent' => array(
            'class' => 'event',
            'other_field' => 'subscriber'
        ),
        'ownedevent'=>array(
            'class'=>'event',
            'other_field'=>'owner'
        )

    
    );

I have a join table called events_users with columns: id, subscriber_id, subscribedevent_id, owner_id, ownedevent_id

in my controller, If I call

$event->save($owner, 'owner');

$event->save($subscriber,'subscriber');

It does.

Am I doing something wrong?  The owner_event relationship saves if I move ‘owner’ into the $has_many array but event should only be allowed to have one owner. Is this the correct way to do it or is there a way where I can constrain it to a has_one relationship?

Thank you.