Thanks for your comments, demerphq ;). I wonder if I didn't make my goals very clear. I'm not so out of touch that I really want to build a complete autodetecting replacement for Class::DBI. I want to make the "simple" things automatic, and try to make the definition of "simple" encompass as much as is reasonable. Integrity constraints, composite primary keys -- these are not in my definition of "simple" at the moment, and you are right, a naming-based system like this will start getting nasty (read: unreasonable) if I tried. I don't want the whole kitchen sink.. I want a self-loading and self-emptying dishwasher ;)

I suppose my target audience would be anyone who wants to quickly write some glue code where the data is to stored in a "simple" DB. Maybe even this is unreasonable by your definition of "serious work", but in my experience I've written a lot of small projects where the database schema really is this simple. If you start out a project and decide your data needs composite keys, integrity constraints, whatever.. by all means don't use this! In the case where an application starts out within the scope of my module but grows to be too complex, I'd like to think that the OO interface being not entirely dissimilar to Class::DBI, a migration wouldn't be totally unreasonable. You give a really good example about projects growing beyond the scope of this type of thing, but I hope that the possibility of that happening doesn't make it a useless project, or scare people from at least trying it.

One thing you bring up that I really do want to have a plan for is the mother/father relation example. I've run into this when trying to represent a tree in the database (using a parent column). It's a situation that's common enough that I should have a plan for it. The biggest problem is that MySQL not only ingores, but doesn't even store foreign key metadata on a column (Update: Oops: except on InnoDB tables, thanks perrin ;)). With Postgres or some other "real" RDBMS, I could autodetect these with the foreign key info in the metadata. Maybe this will be the thing to finally convince me to switch (although my webhost still has only MySQL). The only problem might be automating a good name for the reverse relation. The relation is "parent" in one direction and "child" in another, which might not be easy to automate (although the idea of using some Lingua modules to do it intelligently is very exciting).

blokhead

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.