Don't ask to ask, just ask | |
PerlMonks |
Re: Re: Module RFC: Yet another object-persistence interfaceby blokhead (Monsignor) |
on Sep 21, 2003 at 17:27 UTC ( [id://293008]=note: print w/replies, xml ) | Need Help?? |
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
In Section
Meditations
|
|