Christopher Hicks <[EMAIL PROTECTED]> writes:
> Personally I'd like to see a solution based on AppConfig. We have our
> database configs in AppConfig. The config files look something like:
>
I did that two years ago:
http://search.cpan.org/author/TBONE/DBIx-Connect-1.13/lib/DBIx/Connect.pm
On Fri, Dec 17, 2004 at 03:17:25AM +, Terrence Brannon wrote:
> Christopher Hicks <[EMAIL PROTECTED]> writes:
>
> > Personally I'd like to see a solution based on AppConfig. We have our
> > database configs in AppConfig. The config files look something like:
>
> I did that two years ago:
>
On Tue, 7 Dec 2004, Christopher Hicks wrote:
> I don't care about Oracle or any of the rest. Making this work with PG
> and MySQL will solve 90% of the world's problems. I don't see why it
> couldn't be extended to include whatever parameters where necessary for
> any of the proprietary database
On Tue, Dec 07, 2004 at 04:40:51PM -0500, John Siracusa wrote:
> On Wed, 08 Dec 2004 10:21:35 +1300, Sam Vilain <[EMAIL PROTECTED]> wrote:
> > I think that this information should be removed from most programs
> > altogether. They should just have to specify a logical data source
> > (possibly inc
On Tue, Dec 07, 2004 at 11:51:41AM -0600, Chris Josephes wrote:
>
> Either way, does this traffic need to be replicated on both dbi-users and
> module-authors?? I would think the DBI list would supercede the other.
I agree.
Can anyone replying to this thread please remove [EMAIL PROTECTED]
from
On Wed, 08 Dec 2004 10:21:35 +1300, Sam Vilain <[EMAIL PROTECTED]> wrote:
> I think that this information should be removed from most programs
> altogether. They should just have to specify a logical data source
> (possibly including a schema version), then a module with a config file
> maps that
Orton, Yves wrote:
DBD::Ingres does something similar. DBD::Oracle appears to be closer to
Sybase/MySQl:
"dbi:Oracle:host=myhost.com;sid=ORCL"
Normally you don't bother with connection parameters with Oracle at all:
DBI->connect("dbi:Oracle:", "database", "password");
Instead, you configure which
On Tue, 7 Dec 2004, Orton, Yves wrote:
I was given the Henrik or some other hypothetical respondant the benefit
of the doubt.
I figured that out by the end of reading your email.
:-)
:-]
I thought it was clear I think that this is both doable and worth doing.
Yes yes. I didn't think there was muc
Christopher Hicks wrote:
> > Coming up with common set of parameters that most DB's are going to
> > require and then providing standardized names for them would seem to be
> > useful in general. So far I havent seen anyone provide something that a
> > given driver Has To Have that doesn't fit i
On Tue, 7 Dec 2004, Orton, Yves wrote:
To: 'Henrik Tougaard' <[EMAIL PROTECTED]>,
'Martyn J. Pearce' <[EMAIL PROTECTED]>, Tim Bunce <[EMAIL PROTECTED]>
Cc: Sam Vilain <[EMAIL PROTECTED]>, Ken Williams <[EMAIL PROTECTED]>,
Terrence Brannon <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL P
On Tue, 7 Dec 2004, Henrik Tougaard wrote:
Maybe the number of responses on this thread come from people who
have this itch to scratch.
Huh? I've only been seeing what got cross-posted on this to
module-authors until today, but I just subscribed to dbi-usres
n
I have heard Tim Bunce (DBI, DBD::Or
Henrik Tougaard wrote on 07 December 2004 10:59
> Martyn J. Pearce skrev:
> > On Fri, Dec 03, 2004 at 11:25:53AM +, Tim Bunce wrote:
> ...
> >> The simplest fix is to standardize one set of driver DSN attribute
> >> names so that at least the host, port, and database (schema) can
> >> be specif
Martyn J. Pearce skrev:
> On Fri, Dec 03, 2004 at 11:25:53AM +, Tim Bunce wrote:
...
>> The simplest fix is to standardize one set of driver DSN attribute
>> names so that at least the host, port, and database (schema) can
>> be specified in a portable way.
>
> Is that really the simplest? It
On Wed, Dec 01, 2004 at 06:43:51PM -, Orton, Yves wrote:
>
> > It'll always come down to the issue of "why not store complete DSNs?"
> > and so far that's not been well covered by the feedback I've got.
>
> Duplication of data in multiple places is the answer I think. The more DSN
> strings y
> It'll always come down to the issue of "why not store complete DSNs?"
> and so far that's not been well covered by the feedback I've got.
Duplication of data in multiple places is the answer I think. The more DSN
strings you have the more needs to be changed later on, and the bigger the
chance
Orton, Yves stupidly wrote on 01 December 2004 12:54
> Tim Bunce wrote on 30 November 2004 23:32
> > On Tue, Nov 30, 2004 at 09:38:47PM +, Nicholas Clark wrote:
> > > On Tue, Nov 30, 2004 at 08:53:51PM +, Tim Bunce wrote:
> > >
> > > > I don't get it. Can someone give me some small but rea
Tim Bunce wrote on 30 November 2004 23:32
> On Tue, Nov 30, 2004 at 09:38:47PM +, Nicholas Clark wrote:
> > On Tue, Nov 30, 2004 at 08:53:51PM +, Tim Bunce wrote:
> >
> > > I don't get it. Can someone give me some small but real examples
> > > of the problem that's being solved here?
> >
17 matches
Mail list logo
