Have you looked at all the code and utterly pointless machinations it goes through in dealing with that hash in order to do what? To tack all the bits together into a string and pass it on to DBI!

I think you're forgetting the rest of the story. DBI passes that DSN to the DBD, which then (wait for it…) parses it and breaks it back up into pieces again! When you see the whole picture, the "utterly pointless machinations" part is clearly in the middle, where DBI makes you smush up a bunch of separate pieces of information into one of a dozen different database-specific formats, only to have each DBD driver then separate the pieces again in order to do its actual work.

(Well, to be fair, they're not utterly pointless machinations. They basically mark a point where the DBI API punted. Because it couldn't know ahead of time all possible information a DBD driver might want to have passed to it, DBI just shrugged and said "use an opaque string and each DBD can deal with the parsing." (There are other "arbitrarily extensible" data structures, of course. But no, string it was.) Anyway, there's another half of that bargain: the DBI user who has to form that specially formatted string. But hey, not DBI's problem, right? Not the DBI API's best moment, IMO.)

And what does it achieve? Nothing! Just a couple of hundred extra lines of code that complicate the interface and slow things down for no net gain whatsoever.

"No net gain" that you can see, anyway. But first things first. For the original poster, if you have a DBI DSN, you can feed it directly to Rose::DB and it'll attempt to do the parsing-into-components for you. Depending on how esoteric your DSN is, this may be sufficient; no extra code needed.

As for the "gain" of entering and storing this information separately, isn't it obvious? No one wants to remember all the various ways to format DBI DSNs for each DBD::* module. Even within a DBD module there are often many different formats supported. Rose::DB provides an abstraction layer with uniform names and semantics. (Also, storing this information in pieces makes adding, removing, or editing individual components a lot easier and more obvious. It also provides a standardized syntax for the YAML configuration overlay file, yada yada.)

This is perhaps the most common and most useful purpose of any piece of code: abstracting away details that don't matter. This example of DSNs is a microcosm of what Rose::DB does on behalf of Rose::DB::Object, namely isolating it from (or providing a uniform set of introspection methods to determine) the differences between the databases.

In reply to Re^6: Avoiding compound data in software and system design by siracusa
in thread Avoiding compound data in software and system design by metaperl

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.