Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

samtregar (2699)

samtregar
  (email not shown publicly)
http://sam.tregar.com/

Journal of samtregar (2699)

Saturday October 23, 2004
06:28 PM

Another OO DB wrapper fails the join test.

[ #21485 ]
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


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Another OO DB wrapper fails the join test. 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I was taking to DrHyde about this at l.pm last night. I am hoping I may be able to acheive this with Class::PINT. It already provides complex/compound attributes on top of CDBI (via subclassing) as well as inheritance.

    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.

    --

    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;
    • 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

      • 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.

        --

        @JAPH = qw(Hacker Perl Another Just);
        print reverse @JAPH;
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.