in reply to Re^3: Avoiding compound data in software and system design
in thread Avoiding compound data in software and system design

You are making an artificial separation where none exists.
we will see about that (grin)

But the distinction is simple: conceptual elements belong in separate data elements or in a single element with straightforward access. The DBI dsn string has several conceptual elements which are not in separate data elemnets. And access is not straightforward - had a hash reference been used, access would be more straightforward, with no loss in API quality.

But like I said in the opening post of this thread: Typically people either know this and dont need to be told or they dont know it and dont care :) So it's almost like screaming at a wall.

But your comments about URLs are well-taken. I thought about that this morning when I woke up. And in a sense, you could consider DSNs as a form of URL. In fact, SQLAlchemy uses URLs instead of DSNs

Rather than something to be "avoided", DBI's use of a string for the data source name is the sign of a well-though through, flexible interface. One that recognises that you cannot fit the world into labelled boxes, and that in many situations, there is no purpose in trying.
I dont agree: it requires more parsing to decide which DBD to dispatch to this way.
You should be celebrating the vision and skill of those authors for designing an interface so flexible it can accommodate future developments without requiring constant re-writes as time passes and uses evolve. Not decrying them.
$dsn as a hash reference would have been just as flexible and much finer grained. And it would not suffer from a case of compound data. And the code to decide which DBD to dispatch to would've been more succinct. And I would not have had to write DBIx::DBH in order to work with Rose::DB and DBI interchangeably.

The Rose::DB API has finer granularity and does not suffer from the compound data issues that the DBI one does: connection info from Rose::DB can be converted into DBI connection info in a simple fashion, vice versa not so.



The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development.

-- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"

Replies are listed 'Best First'.
Re^5: Avoiding compound data in software and system design
by BrowserUk (Patriarch) on Apr 22, 2010 at 23:45 UTC
    Typically people either know this and dont need to be told or they dont know it and dont care :) So it's almost like screaming at a wall.

    You are deluding yourself. The DBI interface has been around for 15 years. And you are the first person to see this 'need'?

    And I would not have had to write DBIx::DBH in order to work with Rose::DB and DBI interchangeably.

    Have you looked inside Rose::DB?

    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!

    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.

    Rose::Db is essentially a wrapover DBI. And you're writing a wrapover that wrapover so that you can "use them interchangably".

    Sir! Your logic is flawed. Even though you cannot see it. Your logic is flawed.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      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.

[reply]
        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.

        I'm sorry that you think you are performing a useful service. You've forgotten the point of encapsulation. By breaking that encapsultion of the dsns, you are just complicating the life of your users. And "introspection" without good purpose, is no good reason.

        When the postman delivers me a letter, he hands me the envelope. He doesn't read the contents to me, whilst handing juicy details of the sender and contents to my neighbours.

        Yes. DBD breaks out parts of the dsn, but that's its job! But it only looks at those parts it needs to find the right DBD::* module. It hands the rest over to that particular DBD::* module untouched. Because only that module knows what to do with them.

        Another analogy. Take a close look at TCP/IP packets. The application passes a data block. That gets wqrapped in UDP or TCP headers and gets passed to the IP layer where IP headers get added. And that gets passed to the link layer where frame headers get added. To each of these layers, the packet from the layer above is just an opaque lump. And that's exactly how it should be.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Meditations