[Deprecated] DMZ 1.6.2 (DataMapper OverZealous Edition) |
[eluser]TheJim[/eluser]
@Overzealous Directly integrating the iterator for get_iterated into the class is really a slick way of doing it. I hadn't considered that, but I definitely like it.
[eluser]Benedikt[/eluser]
I saw the new "get_iterated()" feature and want to change my code accordingly. Is there a date when 1.7 will be stable? Thanks for this.
[eluser]OverZealous[/eluser]
@Benedikt Not hard set (see the changelog, it's February Soonish, 2010 :-)), but the best way to help get DMZ 1.7.0 out and stable is to download it and test it on a non-production server. It's impossible for me to single handedly tests all cases for all environments. The majority of changes in this version are behind-the-scenes, and I can't be sure that some of them won't affect existing code, but I'd sure like to get as close as possible, especially since this is a performance and bugfix focused upgrade, and everyone should use it! So, if you get a chance, try it out. The only file you have to change for this version is the core DataMapper library. So, you can test it by grabbing the lite version, renaming your current datamapper.php to datamapper.php.bak, and copying in the new file. Test your App. If you get any errors, or odd results, report them, and swap back. If I don't hear from anyone through the weekend, I'll probably go live on Sunday or Monday, 'cause I really wanted to have this out there already.
[eluser]Benedikt[/eluser]
Ok, I will report any bugs I can find but as most of the projects are under construction, could be hard to find. But I guess you didnt change the core functionality too much ![]() The new features look great.
[eluser]OverZealous[/eluser]
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. :bug: (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.)
[eluser]Benedikt[/eluser]
I have a question: I activated Auto_Transactions in Datamapper. Now I want to control the transaction manually in one situation. Is that possible? Because currently I am using trans_commit() and trans_rollback() but even there is an error before it will still write to the database and not roll back. Is there a way in case to make it possible to control the transaction manually without deactivating transactions globally?
[eluser]OverZealous[/eluser]
@Benedikt I don't know your database, but databases that fully support transactions will work with nested transactions. This means you can wrap everything inside one transaction, and then if you rollback the outer transaction, everything inside should rollback as well. Personally, I don't see the point in auto transactions. (It's a leftover piece from DataMapper.) The only time they do anything at all is when saving relationships to a group of objects. Otherwise, they have no benefit. If you need to save the content to more than one object, you still need to wrap everything in a transaction separately. Make sure you are getting a benefit from using auto-transactions.
[eluser]pembelajar[/eluser]
Hi, thanks before for this great library. But, i'm very newbie for this, can you explain how to make this query below on DMZ? Code: $this->db->select('*'); Thanks a lot.
|
Welcome Guest, Not a member yet? Register Sign In |