Front page | perl.dbi2.dev |
Postings from October 2005
Adam Kennedy wrote: > Where is my DBI::DSN object, that contains the connect information and > that I can serialize and deserialize easily. Something I can validate as > a connect string BEFORE I actually have to use it. And what *common* methods/attributes should that object have, besides a "toString" method? Note, that there is absolutely *nothing* that (for example) a DSN like "DBI:Oracle:somesid" and "DBI:mysql:hostname" have in common, although they look quite similar. > I'd bet that people have had to implement this over and over again > themselves. Many of the issues about connect strings being hard to parse > go away if DBI2 gives us a DSN class that does it for us, and does it ? > for every driver regardless of whether or not it is installed. Even if > it can't know all the details, it should at least know what typeof > driver it is, etc. My impression is that we are mismatching the DSN or the "DSN object" with Tim's suggestion for introducing more meta data here. I admit, that it may be desirable being able to parse and/or construct a DSN. However, the question is: Who does it? DBI or the driver? To me, the answer is that DBI should leave it's hands off as much as possible. JochenThread Previous | Thread Next