To be honest, I have always been less than impressed with the current state of RDBMS-OO mapping modules out there. There are some that are nicer than others, but none of them have felt comfortable to me. I welcome another player in the market, maybe skyknight's will be the one that strikes my fancy.

Of course, many will say that there is no point in re-inventing the wheel, but in the case of RDBMS-OO mappers, I am not sure that the current state of wheels (in any language) are really as best as they can be.

Here are some interesting links on the subject though:

• http://poop.sourceforge.net/
• DBI Wrapper Feature Comparison

Indeed... In fact, the inspiration for the module that I have written comes from a home grown module to which I was exposed at a former job. It had some very good concepts (that I've cherry picked as best I can), but also many serious flaws that were very problematic time and time again. On my own, I have written three different iterations, all inspired by that original module for various projects or consulting jobs. This will be the fourth iteration of my attempt to forge something that lives up to the potential of the original.

I've really struggled with this module to avoid kludgey compromises, and I hope that that will shine through in the (purported) elegance of the API. Execution efficiency has also been a big concern, as the database at my job which is serving as a pilot project is of the order of tens of millions of records.

One of the key issues with which I wrestled was how to instantiate a large collection of objects, associated with their children in one-to-many has-a relationships, while neither executing superfluous queries nor pulling in extra information in the join operations. The solution to this was to issue one query for the collection of objects being loaded, and one query for each of the has-a relationships, ordering the object query by its surrogate primary key, and each of the has-a link table queries by the associated foreign primary key. The best image I can conjure for this process is the zipping of an n-threaded zipper where different segments of the various zippers have to be shifted to match up. :-) Presumably other OO-mappers have successfully wrangled with this problem before me, but I was pretty happy with myself for working out all the details. The original module of which I spoke totally punted on the issue, instead assuming that the user would never simultaneously load multiple objects that had one-to-many relationships.

Oh, and both of your links seem like excellent resources to promote the uniqueness of my own module, something that, as jZed pointed out in another comment, is of utmost importance if I am going to stimulate any interest in my module.

Thanks again.

One of the key issues with which I wrestled was how to instantiate a large collection of objects, associated with their children in one-to-many has-a relationships, while neither executing superfluous queries nor pulling in extra information in the join operations.

I think with these kind of tools, you cannot avoid having some superfluous queries as well as occasionally pulling in extra information. If your tool is so fine grained that it loads too little, it will likely slow to a crawl when trying to retrieve a lot of information. However the same can be true if your tool is too coarse grained, and it grabs much more than it needs each time. Personally I would recommend two possible approaches (which themselves are not mutually exclusive):

Lazy Loading
Load your main objects completely, but all relationships lazily. This will work pretty well for your more basic of DB schemas which have few relationships and contain much of the information for an individual entity in a single row/table. This way when fetching a collection of objects, you can get only as much as you need. But when you really are looking for a single object and all its related information, you can take the time and fetch it all.

Multiple Views for each entity
The idea here is that you are not always going to need the same "view" of an entity and its relationships for all situations. For instance, sometimes you only need the user_name and password information for your User object (both fields contained in the same hypothetical table), while other times you need their first_name, last_name, address, zip-code and phone number as well (contained in one or many hypothetical tables linked to the user table). It makes sense maybe to have two kinds of User objects, one for verifying user_name and password upon login, and the other for printing out mailing labels, each optimized for their specific usages.

Oh, and both of your links seem like excellent resources to promote the uniqueness of my own module,...

Don't get too caught up in the "uniqueness" of your module. There are many here who will cry "Your Re-Inventing the Wheel!", but the fact of the matter is that just because its been on CPAN for 5 years, and has made it into the core module set, blah blah blah, doesn't mean its still the best tool for the job (and in particular the job you are doing) and might not be old and krusty. There is always room for someone to "Build a better Mousetrap" out there, and unless you try, you will never know. However, always keep in mind that in order to build Mouse::Trap::Better.pm you should know about all the other mousetraps available out there so that you can learn from thier mistakes and build upon their success.
-stvn

Obviously this is the kind of thing that would be very useful, and as such I harbored no illusions that I'd be the first to market. I am aware of the existance of the Class::DBI module, and have spent some time looking at it. It is my hope to create a solid competing implementation that more closely approximates my vision of how such a module should work. While doubtless many will disagree that it is "better", I would hope that it will culminate in something to which people give serious consideration as an alternative to Class::DBI. Time will tell whether I will be shown up as a useless crank...