in reply to DBIx::Simple

Nice job. I see it is in CPAN, great!

I've used DBI for years and I liked learning it, and learning it. Maybe the right phrase would be "in an every-learning state". I used to roll my own schema system and still do try to hide SQL in subs. But I have a few queries (sorry).

- at first I felt a little dyslexic reading the hashes/arrays method names. I'd much prefer hashlist/arraylist, or even LoH/LoL. A plural word just got me somehow, maybe you'd like to add a synonym.

- Another niggle, seems that a Group By would be more efficient than doing a query for each order in your example of nested queries on two databases. No problem for your audience I'd guess, but you might like to mention the idea of database overhead in your docs.

- I also was intrigued by DBIx::Easy, the makemap and serial methods for example seemed to answer questions I once had when learning databases, and then picked up or rolled my own. I'm sure you've looked at it, but it does have an interesting take on the meaning of the term "easy".

I was going to suggest doing something more radical to make things easy, something like a smart gun - point it in the general direction of the opposing forces and you get a bullseye. Maybe EasyDB tried to do that. Can you make it even easier than that module? I'm thinking of not forcing the user to do any of those loops or anything, just hand coderefs for an error sub and a sub that says what to do with each returned value. Anyway your take on it seems fine. Was hoping for something easy enough to lure PHP users back to Perl. :)

- I am a little worried about people not being able to step up to DBI, perhaps you'd like to mention differences or things left out with regard to big old DBI. In fact tons of really easy to understand documentation about databases would be wonderful for beginners.

- If there is anything else, I'd ask for more methods that do things common to web site work so that people aren't always rolling their own. One example is authentication and cookies. There are lots of ways to do it, but even if the answer is "leave it to Apache" it would be invaluable for you to provide such a facility with ample installation, usage, and philosophy docs. "Simple" doesn't mean the programmer is simple-minded or uneducated, it could just mean "I've rolled my own umpteen times but would like to get something stable that works done ASAP and go home at a reasonable hour without delving into my code catacombs". So, making hard things Simple would be a good code word. Then making really hard things Simple, etc. (thanks Zeno).

Hope this helps.

Matt

Replies are listed 'Best First'.
Re: Re: DBIx::Simple
by Juerd (Abbot) on Mar 30, 2002 at 13:21 UTC

    - at first I felt a little dyslexic reading the hashes/arrays method names. I'd much prefer hashlist/arraylist, or even LoH/LoL. A plural word just got me somehow, maybe you'd like to add a synonym.

    You will get used to it. The names are logical: hash() returns a single hash(ref), hashes returns multiple of the same.

    - Another niggle, seems that a Group By would be more efficient than doing a query for each order in your example of nested queries on two databases. No problem for your audience I'd guess, but you might like to mention the idea of database overhead in your docs.

    Which example of two nested queries? /me has no idea what you're talking about...

    - I also was intrigued by DBIx::Easy, the makemap and serial methods for example seemed to answer questions I once had when learning databases, and then picked up or rolled my own. I'm sure you've looked at it, but it does have an interesting take on the meaning of the term "easy".

    Hmm, typically, you use all data returned by a query, and not just a little bit of it. It makes sense to loop over the returned results. However, maybe there are cases when such a map comes in handy, and I implemented the idea in 0.02 (to be released soon).

    Extract from the new synopsis: 

    # BUILDING MAPS (also fetching all in one go)

my $customers =
    $db
    -> query('SELECT id, name, location FROM people')
    -> map_hashes('id');
    # $customers is { $id => { name => $name, location => $location },
+ ... }

my $customers =
    $db
    -> query('SELECT id, name, location FROM people')
    -> map_arrays(0);
    # $customers is { $id => [ $name, $location ], ... }

my $names =
    $db
    -> query('SELECT id, name FROM people')
    -> map;
    # $names is { $id => $name, ... }

    [download]
    So the example mentioned in DBIx::Easy's POD would be: 
    $easy->makemap('components', 'id', 'price', 'price > 10')

$simple->query('SELECT id, price FROM components WHERE price > 10')->m
+ap

    [download]
    Yes, it indeed is more typing, but that's because I don't want any SQL abstraction in DBIx::Simple.

    I'm thinking of not forcing the user to do any of those loops or anything, just hand coderefs for an error sub and a sub that says what to do with each returned value. Anyway your take on it seems fine. Was hoping for something easy enough to lure PHP users back to Perl. :)

    That would only make things unclear and therefore not-simple. I think loops should be very clear and visible, not abstracted.

    If there is anything else, I'd ask for more methods that do things common to web site work so that people aren't always rolling their own. One example is authentication and cookies.

    Those things are not tasks for a database interface. DBIx::Simple is in absolutely no way aimed at pulling PHP users, although it would be a welcome side-effect. Perl has much more uses than web development. Maybe one day, there'll be a complete set of PHP modules implementing PHP's built in functions.

    U28geW91IGNhbiBhbGwgcm90MTMgY
W5kIHBhY2soKS4gQnV0IGRvIHlvdS
ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
geW91IHNlZSBpdD8gIC0tIEp1ZXJk

[reply]
[d/l]
[select]

In Section Meditations