No, you wouldn't, because the specially-formatted DSN string never needs to be constructed at all, for any reason.

I see. So you're volunteering to go through and modify all the 600+ DBD::* modules; and all the modules that use them; and all the code written in the last 15 years that use them; just so that you can provide introspection of things that nobody will ever want to introspect?

Let's just pretend for a moment that we could re-write history, and DBI had specified that the first parameter to DBI was a hashref. And (say), the only required pair was dbi => Pg|MySQL|Whatever. And that each DBD was free to require whatever pairs it needed. What does that achieve?

You would have a hash rather than a string. That would make it easier to wrapover in your DSN object--though this parsing you speak of is hardly onerous. But then, as now, that wrapover is pointless.

• A hash is far easier to use than an object.

  $hash{ $key }++ is infinitely preferable to  $dsn->keySet( $key, $dsn->keyGet( $key ) + 1 );

• And apart from using clumsy OO syntax to get, set or iterate the contents of that hash, what else does that dns class do? What else could it do?

  You can't hope to validate all the possibilities. And there are no useful methods beyond get/set/iterate you could apply to it.

  Even ignoring that you'd:

  • either have to standardize the fields in the dsn.

    Which is impractical as each DBD has its own unique set of requirements

  • or eval the setters/getters into existance based upon what the user put in the hash.

    Which besides any problems with eval, means that

    1. DBDs would need to name all their fields.

       Which many own don't currently have, and neither need nor want to have;

    2. you would risk evaling the users typos into existance with absolutely no way to validate them.
• Ultimately, you'd have to provide a method that returned the attributes as a simple hash(ref) in order to pass it to DBI anyway.

  Unless you envisage passing your DSN object to DBI and have it pass it through to the DBDs (another breaking re-write).

  So then all the DBDs acquire yet another dependancy for no good purpose beyond the creation of OO tagliatelle.

So, even if we could ignore history, and turn back the clock to do things your way, there'd be no value in it. And a considerable downside of increased complexity and dependancies.

OO is fine and dandy when used properly, but using it to enforce a one-size-fits-all syntax fetish is no good use. Like all programming tools, the trick is to know when to use--and when not to.

You may think that I don't agree with you, because I haven't tried the KoolAid yet, but you'd be wrong. I tried your flavour of KoolAid (along with most others) a long time ago, I just didn't like it. Or rather, can tolorate all flavours, each is fine for certain occasions, but I see no good reason to limit myself (or others) to just one flavour. Of anything.

I see. So you're volunteering to go through and modify all the 600+ DBD::* modules; and all the modules that use them; and all the code written in the last 15 years that use them; just so that you can provide introspection of things that nobody will ever want to introspect?

Is this really what you think I was suggesting? Or do you actually understand the context within which my previous post was made?

Let's just pretend for a moment that we could re-write history, and DBI had specified that the first parameter to DBI was a hashref.

Ah, it appears you do. I guess that first paragraph was just for "flavor," eh?

You would have a hash rather than a string. That would make it easier to wrapover in your DSN object--though this parsing you speak of is hardly onerous. But then, as now, that wrapover is pointless.

First, in my hypothetical version of DBI, I'd standardize the common names in the hash. For example, if you have something like a database, use the "database" key (not "db", not "dbname", etc.), use "host" for the host (not "hostname", not "server", etc.), and so on. This would be a documented part of DBI. Standardized names would cover at least half of the things commonly specified in DSNs.

Second, I think you still don't understand what Rose::DB actually does. Providing a nicer interface to DSNs is not its primary, or even secondary purpose. Even if it simply passed the registered data source information straight through to DBI, its most important roles would remain unchanged: first and foremost, to provide a uniform interface for database-specific behaviors to Rose::DB::Object; and second, as a registry of logically named data sources, organized in a generic two-level hierarchy (domain and type) with an optional file-based configuration overlay to allow sensitive information such as production passwords to be kept out of the source code, while still using exactly the same code in development and production.

To clarify that first role, the goal is to keep code out of Rose::DB::Object that says "if the database is mysql, do X, else if the database is oracle, do Y, else ..." and so on. (That goal is about 99% achieved; there are a few stragglers.) Instead, such behavior is delegated to the current Rose::DB-derived object, which is an object attribute in Rose::DB::Object (i.e., each Rose::DB::Object-derived object "has a" Rose::DB-derived object in its "db" attribute). This arrangements allows a Rose::DB::Object-derived object to, say, be loaded from one database and then stored into another, even if the two databases use a different server product, as shown in the tutorial. Assume "production" is PostgreSQL and "archive" is MySQL:

# My::DB "isa" Rose::DB
$production_db = My::DB->new('production'); # PostgreSQL
$archive_db    = My::DB->new('archive');    # MySQL

# Load bike from production database
$p = Product->new(name => 'Bike', db => $production_db);
$p->load;

# Save the bike into the archive database
$p->db($archive_db);
$p->insert;

# Delete the bike from the production database
$p->db($production_db);
$p->delete;
[download]

Again, understand that the Rose::DB::Object-derived Product object calls back into its Rose::DB-derived My::DB object whenever it does anything that might vary from one database to another. I hope you'll agree that Rose::DB is just a bit more than a "DSN object."

So, even if we could ignore history, and turn back the clock to do things your way, there'd be no value in it.

There'd be considerable value in that people could use DBI without constantly having to run "perldoc DBD::Whatever" to look up the driver-specific DSN syntax that they don't remember off the top of their head. There's also the added efficiency of not having to parse a string inside the DBD (and not having to write string parsing code in C, as it often is today), and being able to add new attributes without worrying if there's "room" in the current DSN syntax or having to make a second or third syntax, as many DBD::* modules have done, to accomodate new/different parameters. Finally, 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.

Two questions for you:

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

   When every RDBMS worthy of the name has archiving solutions that are safer, more reliable, often transparent, and faster. And that avoid all the obvious compatibility issues.

   PgSQL, DB2, Oracle, SQL Server, and even MySQL.

2. 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)?

---

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