Re^6: Avoiding compound data in software and system design

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.

Comment on Re^6: Avoiding compound data in software and system design

Replies are listed 'Best First'.
Re^7: Avoiding compound data in software and system design by BrowserUk (Patriarch) on Apr 28, 2010 at 06:33 UTC
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. RIP an inspiration; A true Folk's Guy	[reply]
Re^8: Avoiding compound data in software and system design by siracusa (Friar) on Apr 28, 2010 at 12:41 UTC
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. You're (still) missing the point. The "job" of a DBD module is to do database-specific stuff on behalf of DBI. Connecting to the database is "database specific stuff." Parsing separate pieces of connection information out of a string that's heretofore completely unknown and irrelevant to said database product is not. It's extra busywork. Were the DBD handed, say, an arbitrary hash of connection values, it'd merely have to pluck out the bits it needs. No string parsing required. Ditto for DBI "figuring out" what DBD to use by parsing the information out of this string. The same information would be better provided separately (e.g., as a hash key or a separate parameter) Another analogy. Take a close look at TCP/IP packets. The application passes a data block. That gets wrapped 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. This analogy is great because it highlights how far off track you've gotten. What you're describing is a form of serialization. Serialization is used to send compound information over a "linear" transport (e.g., a network connection). Serializing data only to pass it as a parameter to a local function call, which then has to de-serialize it, is dumb. No matter how many intermediate layers the arguments pass through, they can be passed along as-is, whether they're in a hash ref, an array ref, a list, or whatever. Serialization is not necessary or useful until/unless this data has to be written to or read from a serialized entity such as a file or network connection. (And even in that case, "arbitrarily formatted string" is much worse choice than, say, YAML, JSON, or any of the other standardized formats specifically designed for this purpose.)	[reply]
Re^9: Avoiding compound data in software and system design by BrowserUk (Patriarch) on Apr 28, 2010 at 13:30 UTC
You're (still) missing the point. No. I'm not. What you're describing is a form of serialization. No. It isn't Serialisation would mean that the data existed in some structured form at the application level. It doesn't. Because it doesn't need to be known at that level. The envelopes are added as you descend through the layers; information that only that layer of encapsulation is party to. Added on the way in, stripped away on the way out. Read the RFCs. And if that's too difficult for you, start here. And make special study of the contents of the box on the right hand side. It is that encapsulation that allows IPv6 to be inserted into the stack underneath applications, without the applications needing to know anything about it. If those envelopes existed as structures at the application level, every application would have to be modified in order to use IPv6. Say what you will about the guys that invented that stuff--they may be old and grey, but they knew what they were doing. And what you're doing in Rose::DB, by breaking the encapsulation of DSNs is exactly analogous to that. It is unnecessary, pointless and creates work for the application programmer. Your users. The OP for instance! I know you think you know better, but 5 years or 10 from now, the penny will drop and you'll get it. Till then, we'd best just agree to differ, because you obviously aren't getting it now. 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. RIP an inspiration; A true Folk's Guy	[reply] [d/l]
Re^10: Avoiding compound data in software and system design by siracusa (Friar) on Apr 28, 2010 at 14:12 UTC
Re^11: Avoiding compound data in software and system design by BrowserUk (Patriarch) on Apr 29, 2010 at 11:29 UTC


The stupid question is the question not asked
	PerlMonks