I’m already thinking ahead to DMZ 2.0, which will probably be the next big release after 1.7 goes live…
Since performance has been on my mind, I’ve been thinking about the number one fixable memory hog since DMZ 1.6: the $db (CI_DB) object(s).
A little history
In 1.6 I redesigned DMZ to allow the $db object to be created as needed. This enabled multiple queries to be built and run simultaneously, as well as enabling the subqueries feature. Any time a query is run on an object, that object (by default) gets it’s own copy of $db. (This also made it easier to support connecting to multiple DBs at once.)
However, this can have some serious side effects if you are running a lot of different queries on one page. Some of it can be alleviated using a better architecture (e.g., implementing PGPool for PostgreSQL databases, and then disabling pconnect in CodeIgniter). But the sad thing is that it is completely unnecessary: the only reason for this setup is the way ActiveRecord is integrated into the database driver(s). It’s the AR functions that need duplicates, not the database connections.
I think I’ve wrapped my mind around how to make this work, however, with minimal effort and code changes. I can basically copy-and-paste the ActiveRecord code into a new class (while making improvements and deleting deprecated methods), and then use that on the DMZ object in place of CI_DB. The actual DB methods will then pass off to a shared (or shareable) copy of the real DB.
I’d then recommend that you disable CodeIgniter’s ActiveRecord altogether.
If I’m careful enough, I don’t even think it will break existing code, even code that works with $object->db directly. 🐛 (I can safely hand off any methods to the real CI_DB using __call!)
One of the benefits of this is that I can fix some of the more annoying AR bugs, such as preventing _protect_identifiers from being called on subqueries and functions.
Another design choice is: do I inline this new, very large class in the already ridiculous datamapper.php file, or do I break it out into its own file? If I break it out, should I break out the other classes in use? And then, where do I store them? APPPATH/datamapper, APPPATH/libraries? I’ll think about that as I get nearer.
I would like to get rid of a few things, though, unless they are in use a lot. Mostly, I don’t see the purpose in the ActiveRecord cache methods. Even now you can get better results via get_clone, and I think they are confusing, because they really have nothing to do with caching. However, if they are useful, I’ll leave them.
Anyway, just thought I’d mention this.
(There’s really no point to this message, but sometimes I find just writing ideas like this out help me to think them over.)