So I'm working on MKDoc and of course it comes with it's own system for avoiding SQL, this one dubbed simply "lib::sql". Now, I'm no big fan of OO DB wrappers, but the rest of the MKDoc code is quite well conceived, I thought this might be worth its (large) weight in code.
Nope. It doesn't even handle a simple two-table join! It's based on the idea that every object will map to exactly one table and that every query will address only that table. Sigh.
-sam
Once I have released at tested what I have done so far I plan to emable objects to span tables/joins in a nice way.
All I really need are some good test cases and suggestions for how you would expect the API to work.
Re:objects spanning tables
samtregar on 2004-11-05T14:49:48
Why bother? SQL works fine and it's not hard to write once you get used to it. Frankly I find most DBI wrappers to be more trouble than they're worth. They make easy things moderately easier and the hard stuff is just as hard if not harder!-sam
Re:objects spanning tables
TeeJay on 2004-11-08T12:13:55
writing SQL over and over tends to lead to more bugs and poor optimsiation as well as a maintainance nightmare.If your application is object oriented there are several gains from using a OOPF (object oriented persistance framework) such as pre-canned accessors/mutators, persistance, caching, searching and retrieving, much less code to write.
A well designed OOPF stays out of your way and doesn't require your database to become an inpenetrable mess, Class::DBI works nicely with any well structured schema.
Class::PINT enables me to write quite complex classes with a handful of lines both in the class and any code using it.
The value in this is significant when building non-trivial applications with more than a handful of classes.
Some OOPF can get in the way, but a good one should be fairly transparent, and easy to bypass or customise, Class::DBI, on which I have build Class::PINT is just that.
