So, what happens if you've been using DBI and you have all your connect data in configuration files with DSN strings and then you decide you want to start using Rose::DB::Object? You have to find some way of getting the chocolate back from chocolate milk --- you have to break down the compound data in the dsn in order to get out the sub-elements.First of all, it's not the fault of DBI that you decided to store DSN strings in your configuration file. If you had stored it as (for instance):
it would trivial to construct a dsn, and to parameter list for Rose::Db::Object. You could also share the configuration file with applications written in a different language.driver = mysql host = localhost username = joe password = s3c41+ port = 3306
Second, if you're switching your API from DBI to Rose::Db::Object, I'd think you'll have a change a lot of your code anyway. Parsing out a dsn string shouldn't be that much more work.
In reply to Re: Avoiding compound data in software and system design
by JavaFan
in thread Avoiding compound data in software and system design
by metaperl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |