Thread

DMZ’s main library file contains spl_auto_load function, which is not supported until PHP 5.1.2. So you may want to change server requirement to reflect this?

Anyway, can I just remove the spl_auto_load statement and find another way to load the files? Do you have a recommended way to deal with this problem? I am using php 5.0.0.

I really don’t understand why some people use some buggy versions of PHP. I like to use all the time the latest codes/software . I think a stable code begins with RC…and PHP is already 5.3.1 stable

I think we all would like that. But that’s how my company works. I submit a request for an upgrade; they told me it will be done by the end of next quarter…

Life sucks here. We are using a 10yo solaris box and a version 9 oracle. Apparently the upgrade to php5.0.0 was already a stretch (and oci8 is partially broken as well).

!!!

anyway.

Finally made it to work with CI 2.0 :D, but is slower than CI’s active record

DMZ => 0.0136ms
ActiveRecord => 0.0034ms
Mysql_query() => 0.0012ms

Is this normal?

And is there an option to build database from models?

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.

You are welcome!  I appreciate the support.

I am running into a problem with advanced relationships.

Your code looks correct from here.  😖

One thing is to make sure that the $owner object has been loaded correctly!  It’s an easy mistake to make.

Also, is it possible you have the $has_one relationship defined both as an in-table foreign key AND on your join table?  You only need one.

TABLE events
id ... owner_id // only one of these should exist

TABLE events_users
id ... owner_id // only one of these should exist

If not that, then, one thing you can try is removing owner_id and ownedevent_id from the events_users table, and adding owner_id to the events table.

While it should work just fine storing the owner relationship on your events_users table, you will also see a significant performance gain by using an ITFK, especially with DMZ 1.7, as it optimizes queries to take advantage of them.

Don’t forget to go through the steps listed in the troubleshooting guide, especially the part about checking your queries.

DMZ’s main library file contains spl_auto_load function, which is not supported until PHP 5.1.2. So you may want to change server requirement to reflect this?

Anyway, can I just remove the spl_auto_load statement and find another way to load the files? Do you have a recommended way to deal with this problem? I am using php 5.0.0.

I did not realize that (I’ve thankfully never had to deal with PHP older than 5.2, because I use the JSON functions a lot!)

I’ll take your suggestion and bump the requirements up to 5.1.2.  As for a work-around, all the spl function is doing is loading the models in as they are needed.  I know I “broke” the ability to load models via CI (which will be remedied with 1.7.1), but you can temporarily fix that by removing the private in front of the _assign_libraries function in the main library.  It’s near the bottom.

Another option is to write your own helper or library, or even extension to DMZ that allows you to load the models in as needed.

Sorry to hear about your work environment!  :shut:

Is this normal?

First, ALL ORMs are slower than processing the query directly.  They have to be!  The benefit of an ORM is code-reuse, easier to read code, safer queries, and easier maintenance.  Performance is what is sacrificed to make this.

DMZ uses the CI ActiveRecord.  Are you measuring just the query?  Or the entire page?  How many runs did you measure?  One run tells you nothing, because the server could be having a hiccup at that moment.

DMZ is an ORM — so remember that it has to instantiate each result as an object.  1.7 includes a new format, get_iterated, that allows the code to only instantiate items as needed, however, there are use cases for it.  It doesn’t replace every normal get.

Also, compare the queries being generated.  Did you specify which columns to query?  DMZ is pretty smart, but remember, it’s automatically building a query.  It doesn’t have the ability to predict what you want, so it queries exactly what you ask.

And is there an option to build database from models?

No.  DMZ uses the database to learn about the models, not the other way around.

function test(){
        
        //DMZ Test
        $this->benchmark->mark('start');
        
        for($i=1; $i<=1000; $i++){
            $u = new User();
                $u->username = "test";
                $u->password = "test";
                $u->first_name = "test";
                $u->last_name = "test";
            $u->save();
        }
        
        $this->benchmark->mark('end');
        
        echo "
DMZ: ".$this->benchmark->elapsed_time('start', 'end');
        
        
        //Active Record Test
        $this->benchmark->mark('start');
        
        for($i=1; $i<=1000; $i++){
                $insert['username'] = "test";
                $insert['password'] = "test";
                $insert['first_name'] = "test";
                $insert['last_name'] = "test";        
        
            $this->db->insert('user', $insert);
        }
        
        $this->benchmark->mark('end');
        
        echo "
Active Record: ".$this->benchmark->elapsed_time('start', 'end');

    
    //Pure SQL Test
    $this->benchmark->mark('start');
        
    for($i=1; $i<=1000; $i++){
        mysql_query("INSERT INTO `user` (`username`, `password`, `first_name`, `last_name`) VALUES ('foo', 'bar', 'chh','asdasdasd')");
    }
    $this->benchmark->mark('end');
        
    echo "
Pure SQL: ".$this->benchmark->elapsed_time('start', 'end');
    
    }

DMZ: 1.9113 , 2.0543 , 2.2763 s
Active Record: 1.7360 , 1.5230 , 1.6436 s
Pure SQL: 1.2210 , 1.1639 , 1.2076 s

How did I run them?
On DMZ run, AR and SQL were commented
On AR run, DMZ and SQL were commented
On SQL run, AR and DMZ were commented

@Mareshal
First: those numbers aren’t that far apart.  Remember that everything the raw SQL does, the AR method has to do, and everything the AR method does, the DMZ method has to do.

Second: DMZ validates the data on every save.  This is on purpose, and one of the key reasons to use it.

Third: DMZ looks up the ID after each insert, effectively doubling the number of queries.

I know this is a test, but you are dealing with absurdly small numbers here.

Basically, there’s nothing else to say.  DMZ is going to be slower, as I said, because it is a wrapper around AR which is a wrapper around SQL.

Heck, I’m more amazed that the overhead is so low, given that you are creating 1000 independent objects (actually, it’s probably closer to 3000-4000 objects, with the error, db, and other classes), running 1000 validations, AND DMZ is actually running at least 2x as many queries!  And this is over the straight ActiveRecord version.

Don’t worry so much about optimization.  The overhead used by DMZ is actually insignificant compared to the database and other PHP code in nearly every application, unless you are really trying to use it incorrectly. 😉  (Well, at least in 1.7, since you can use get_iterated to iterate over large result sets.  Which is amazingly efficient.)

I’ve corrected my last post, because I wrote “ms” instead of “s”.

Thanks for such detailed explanation. Anyway, DMZ is much faster than Doctrine 1.2 which has an average of 3.5s. Good work

I’ve corrected my last post, because I wrote “ms” instead of “s”.

I wondered about that!  😉

Thanks for such detailed explanation. Anyway, DMZ is much faster than Doctrine 1.2 which has an average of 3.5s. Good work

That really amazes me.  I would assume a dedicated ORM, which has a lot more flexibility than one tied to a second framework, would surely beat my little code 😛!  That really goes to show how amazingly lightweight CodeIgniter is.

I can thank TheJim for helping on that front, though, as he really helped pare down some of the performance issues that plagued 1.6 and earlier.

Anyway, I wish you good luck working with DMZ!

I really want to work with DMZ but I have a 2 more questions:
1. For how much time will it me maintained and how many people are working on it ?
As a small comment, I’ve asked Doctrine manager to tell me how to upgrade from 1.2 to 2.0 and the answer was “YOU CAN’T”, so all big companies using Doctrine 1.2 and want all bugfixes, will need to rewrite their code. whic was the answer. They changed a lot of methods and classes.
2. Is there any SVN/Mercurial version? You should really use a free SVN/Mercurial host, or something like that. Is very useful to submit bugs/suggestions.

Of course, there’s no need to answer if you don’t want. I am just curious to see how reliable is DMZ for my future projects.

The short answer won’t make you happy: I’m the only developer.  For the foreseeable future, this won’t change, although I accept suggestions and patches.

I do maintain it in an SVN repository, but it is privately hosted.  I’m thinking about migrating to mercurial - but that benefit is for me, not necessarily to open it up more.  I’m kind of the DMZ dictator, and I don’t want turn this into a full-time job just verifying check-ins, etc.  😊

However, the good news is that everything that is important for developing DMZ is included in the download.  It is ridiculously open-licensed, so anyone can take it copy it, modify it, resell it, or whatever.  The only thing is that I retain copyright over the phrase “OverZealous”, the DMZ logo, and there are some less-openly licensed graphics in the sample application.

I use DMZ exclusively in my own application (ZestyJobs), and will maintain it as long as I am able to.  The only thing I’ve cut back on is supporting the HTMLForm extension, because it was just too much code for me to maintain alongside DMZ.

As far as upgrades go: The only things I plan on changing between 1.X and the eventual 2.X are not so dramatic.  I’m mostly planning on clearing out legacy code, possibly migrating some of the lesser-used functions to extensions, so they don’t take up resources (and lines of code) if they aren’t needed, and those sorts of changes.  I also may re-format the entire code base, because I personally don’t like having the braces on their own line (I’m a Java guy originally).  😛

There will be an upgrade path, and it should be fairly painless.  The majority of upgrade hurdles so far have affected developers who needed, for one reason or another, to access non-API methods, or manipulate undocumented internal properties.

One thing that might change that is how much work is needed to support CodeIgniter 2.0.  If CI 2.0 requires a significant rewrite, I may use DMZ 2.0 as a clean break.  However, as long as I’ve switched to Hg by then, I should be able to support both the 1.x and 2.x lines simultaneously for a while.

Finally, I most likely won’t be supporting CodeIgniter 2.0 until it is released.  It just isn’t high on my priority list.

Sheesh, I’m extra loquacious today. :lol:

My turn now:
Maybe you don’t believe me, but I am more than happy now. A one man work is better than a team sometimes. On the entire project is ONLY your coding style and standards, comments and so on. The “How many people” question was a small trick 😉

Btw, are there any major bugs?

CodeIgniter won’t change too much on 2.0 version I think. Most of the changes are already made.

offtopic: Java guy 😛 ? I put the first brace on the same line with the function/method, not like C/C++. Actually I am a student, and at university I learn c/c++/c# , now I am programming microcontrollers using C , but honestly I learned C++ from PHP. In CI I understood what’s the role of __construct, classes, OOP and many other things, even if teachers explained us, was hard. I put much much more effort learning PHP/CI/SQL than c++.

Another problem now, I think I am too tired now, but I’ll post it.

function add(){
        $u = new User();
            $u->username = $this->input->post('username');
            $u->password = "pass";
            $u->first_name = "first_name";
            $u->last_name = "last_name";
            //echo $u->error->string;
        $u->save();
        
        $return['err'] = $u->error->string;
                
        if(!empty($u->error->string))
            $this->load->view('form', $return);
        else    
            echo "Added";
    }

I have a form and when I click submit I want to show the error. This works, but is not good, because UPDATE is made before testing the values. another way?