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

[siracusa]

Why would anyone use a Perl script, to back up a PostgreSQL production server, to a MySQL backup?

It's just an example. Most people only use one database type (though there are exceptions, and even scenarios just like the one described above; people do all sorts of things in the real world). But even when you're using just a single database, the particular, single set of database-specific behaviors you're invoking are delegeted to Rose::DB by Rose::DB::Object. That's the division of labor between the two modules that I was trying to illustrate.

How are you going to handle DBI_DSN, DBI_USER & DBI_PASS? Ancillary: How are you going to fit your hash into an environment variable (or 3)?

I covered that at the end of the last post: "since a serialized format does actually have its uses (e.g., when stored in a file or sent over a network connection), DBI could support one or more of the standard formats that can be used to serialize a Perl hash into a string: JSON, YAML, Data::Dumper, etc." Add to the examples "...or when stored in environment variables." User/pass could be kept as separate parameters or could be incorporated into the hash.

[BrowserUk]

It's just an example.

A very poor example that does nothing to justify the need to objectify DSNs.

Let's just assume for a moment that there is a legitimate purpose for using two different RDBMSs in a single application. And ignore that you can just open two standard DBI connections to them. And that Rose::DB has some useful part to play in that scenario(*). Then what is the need or benefit of Rose::DB abstracting the DSNs? Either as hashes or objects?

• You cannot use the same hash/instance for both connections because they contain different information.
• The only even vaguely consistantly common aspects across even just a sizeable subset are: the constant 'dbi'. and the user & pass fields.
• And even if both connections have the latter two, it would probably be considered unwise to use the same userid and passwords for two different DBs.
• You cannot validate any of the fields except the constants.
• Beyond setting, getting and (re)serialising them, there are no useful methods that can be applied to them.

  Hence, they become nothing more than objectified structs.

There is no advantage in hashifying or objectifying them

And once you recognise that, there is certainly no benefit in trying to stuff multi-line serialisations of them into environment variables. And yes, I realise that some of those formats can be formatted as single lines, but have you ever tried editing them when formatted that way?

Which means you'd now need to use some kind of tool to edit, then compact, them before stuffing the env vars. And that's a nonsense. It defeats the simplicity of purpose that environment variables have had for 40 years or more.

And still you haven't given any specific reason for Rose::DB needing to have these "opaque tokens" broken out as structured entities rather than just leaving them as they are?

And I mean needing! Not just a capricious choice.

(*)(I'm not suggesting it doesn't, I just haven't gone into it enough to know one way or the other.)

[siracusa]

Then what is the need or benefit of Rose::DB abstracting the DSNs?

We're going in circles now. As discussed earlier, the benefit is that the user is freed from having to remember obscure DSN formats, and can inspect the individual pieces easily. The "standardized names" I talked about in my hypothetical DBI example exist in Rose::DB: host, username, password, database, driver, etc. And don't forget, for those who do want to use DSN strings for some reason, Rose::DB will accept them as input in lieu of the individual components, and will produce them as output.

Furthermore, your continued characterization of Rose::DB objects as glorified structs or objectified DSNs means that you're either choosing to ignore or still don't understand the more substantial purpose of Rose::DB (especially as it relates to Rose::DB::Object, though some people do use Rose::DB on its own). Look at some of its methods: parse_interval(), format_timestamp(), next_value_in_sequence(), supports_select_from_subselect(), format_table_with_alias(), likes_uppercase_table_names(), auto_quote_column_name(), validate_boolean_keyword(). Common interface, database-specific implementations. Connecting to the database is just the start of Rose::DB's work.

[BrowserUk]

We're going in circles now. As discussed earlier,

Not in circles. I keep asking the same question, because you haven't yet answered it.

None of that consistutes a need.

1. the user is freed from having to remember obscure DSN formats"

   They don't have to "remember". They just cut and paste from the appropriate DBD docs.

   Your way, they not only have to look up those docs to find out what each particular DBD requires; they also have to look up your docs to find out the "standardised names"; and then work out how to map bits of those opaque tokens to them.

   And then wonder what to do about the names they don't have bits for; and bits you don't have names for.

2. and can inspect the individual pieces easily

   Why do they need to "inspect the pieces"? How will they use that ability?

   Just having that ability, 'because you can', isn't a reason for having it.

   Just being able to use that ability isn't a reason for having it.

   There has to be a purpose for using it. And you've obstinately failed to suggest even one.

3. The "standardized names" I talked about in my hypothetical DBI example exist in Rose::DB: host, username, password, database, driver, etc

   Now that is a circular argument.

   They have to give you them in bits, because you have names for them.

   And you have names for them, so that they can break them into bits.

   But (again) for what purpose or benefit?

4. And don't forget, for those who do want to use DSN strings for some reason, Rose::DB will accept them as input

   So, they don't need them. And neither do you I suggest.

   I've looked. Not exhaustively, but I have looked. And I cannot find one place where you do anything with those fields beyond set them and get them. Not one substantive flow control, validation, ... nada.

Furthermore, your continued characterization of Rose::DB objects as glorified structs

I have never characterised Rose::DB objects as such. Just the breaking apart of DSNs.