Re: DBI v2 - The Plan and How You Can Help

On 8/17/05 5:39 AM, Tim Bunce wrote: > On Tue, Aug 16, 2005 at 03:58:54PM -0400, John Siracusa wrote: >> I think it'll take years, and much actual production experience building >> Perl 6 modules before the community learns what works and what doesn't for a >> Perl 6 API (let alone implementation).

Re: DBI v2 - The Plan and How You Can Help

On Tue, Aug 16, 2005 at 12:12:02PM -0700, Dean Arnold wrote: > Tim Bunce wrote: > > >And nobody mentioned JDBC as a potential model. Odd that. > > I was sorely tempted to do so (and did mention it a few times in > my posts, along w/ ODBC and ADO.NET), but there are some things about > JDBC which

Re: DBI v2 - The Plan and How You Can Help

On Tue, Aug 16, 2005 at 01:16:19PM -0700, Darren Duncan wrote: > At 4:04 PM +0100 8/16/05, Tim Bunce wrote: > >I was a little dissapointed that there wasn't greater focus on using > >Perl6 features - especially as it would have helped kick-start my own > >understanding of Perl6 topics that I expect

Re: DBI v2 - The Plan and How You Can Help

On Tue, Aug 16, 2005 at 03:58:54PM -0400, John Siracusa wrote: > On 8/16/05, Tim Bunce <[EMAIL PROTECTED]> wrote: > > I was a little dissapointed that there wasn't greater focus on using > > Perl6 features - especially as it would have helped kick-start my own > > understanding of Perl6 topics that

Re: DBI v2 - The Plan and How You Can Help

Tim Bunce wrote: And nobody mentioned JDBC as a potential model. Odd that. I was sorely tempted to do so (and did mention it a few times in my posts, along w/ ODBC and ADO.NET), but there are some things about JDBC which rub me the wrong way (e.g., explicit set/get methods for every data typ

Re: DBI v2 - The Plan and How You Can Help

At 4:04 PM +0100 8/16/05, Tim Bunce wrote: I was a little dissapointed that there wasn't greater focus on using Perl6 features - especially as it would have helped kick-start my own understanding of Perl6 topics that I expect to be significant (such as Roles and Pairs, to pick two at random). Per

Re: DBI v2 - The Plan and How You Can Help

On 8/16/05, Tim Bunce <[EMAIL PROTECTED]> wrote: > I was a little dissapointed that there wasn't greater focus on using > Perl6 features - especially as it would have helped kick-start my own > understanding of Perl6 topics that I expect to be significant (such as > Roles and Pairs, to pick two at

Re: DBI v2 - The Plan and How You Can Help

On Sat, Jul 09, 2005 at 10:25:32PM +1000, Adam Kennedy wrote: > >In particular, the DBI must not mandate impossible levels of support from > >the drivers. It will benefit you nothing if the DBI is immaculate and > >wonderful and incredibly all-singing and all-dancing, but no-one can write > >a d

Re: DBI v2 - The Plan and How You Can Help

On Sat, Jul 02, 2005 at 01:06:02AM +0100, Tim Bunce wrote: > Once upon a time I said: I'm back now and, after digesting a small mountain of non-DBI related emails, I'll start digesting all your replies and getting up to speed with Perl 6. Many thanks to all who replied on and off-list. Tim.

Re: DBI v2 - The Plan and How You Can Help

On Thu, Jul 07, 2005 at 08:32:47AM -0500, Jones Robert TTMS Contractor wrote: > > When I go to the donation page and attempt to make a donation, the > drop-down box does not give DBI as a valid recipient. Is it possible > several people may not have donated as they noticed the same results,

Re: DBI v2 - The Plan and How You Can Help

We could have an option to do Bulk Inserts ..

Re: DBI v2 - The Plan and How You Can Help

On 7/14/05, Sam Vilain <[EMAIL PROTECTED]> wrote: > Of course it will be entirely possible to layer support for this sort of > thing atop any DBI interface; Exactly my point. Please be so kind as to implement your ideas in a DBI extension. Time and community will prove whether you are right by us

Re: DBI v2 - The Plan and How You Can Help

Dean Arnold wrote: Column 3 is a BYTEA column in Pg and needs special peppering to work. What sort of "peppering" ? DBI provides SQL_BLOB, and SQL_CLOB type descriptors (as well as SQL_BLOB_LOCATOR and SQL_CLOB_LOCATOR), so presumably DBD::Pg (or any other DBD supporting LOBs) provides the logic

RE: DBI v2 - The Plan and How You Can Help

-Original Message- From: Sam Vilain [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 5:04 PM To: Dean Arnold Cc: dbi-users@perl.org; dbi-dev@perl.org; perl6-language@perl.org Subject: Re: DBI v2 - The Plan and How You Can Help >Dean Arnold wrote: >> RE: LOBs and "S

RE: DBI v2 - The Plan and How You Can Help

org; perl6-language@perl.org Subject: RE: DBI v2 - The Plan and How You Can Help -Original Message- From: Sam Vilain [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 5:04 PM To: Dean Arnold Cc: dbi-users@perl.org; dbi-dev@perl.org; perl6-language@perl.org Subject: Re: DBI v2 - The Plan a

Re: DBI v2 - The Plan and How You Can Help

Dean Arnold wrote: RE: LOBs and "SQL Parse Trees": having recently implemented LOB support for a JDBC driver (and soon for a DBD), I can assure you that SQL parse trees are unneeded to support them. For databases Great! Perhaps you can shed some light on how to do it for this, then. SQL comma

Re: DBI v2 - The Plan and How You Can Help

BTW: If you need a list of DBD's meeting said requirement, let me know, I just pulled one down. Sure, send it over. [ ] DBD-ADO-2.94.tar.gz 31-Jan-2005 02:4041k GZIP compressed docume> [ ] DBD-ASAny-1.13.tar.gz 31-Oct-2003 15:0030k GZIP compressed docume> [ ] DBD-Amazon-

Re: DBI v2 - The Plan and How You Can Help

RE: Placeholders: since DBIv1 already supports both forms of PH's, I see no reason to deprecate or abandon either form. Furthermore, to my knowledge, none of (ODBC, JDBC, ADO.NET) has abandonded or deprecated the ? form, so I don't see the need for DBI to. RE: LOBs and "SQL Parse Trees": having r

Re: DBI v2 - The Plan and How You Can Help

Darren Duncan wrote: I should emphasize that I never expected to be able to send any type of ASTs over the pipe to the database. They would still be interpreted by the database driver for Perl and/or a wrapper thereon, into the database native format. Its just that, to an application, it woul

Re: DBI v2 - The Plan and How You Can Help

At 6:30 PM -0700 7/11/05, Dean Arnold wrote: RE: SQL Parse Trees (or other non-SQL query input) Since none of (ODBC, JDBC, ADO.NET) seems compelled to impose this concept on driver writers, I don't see why DBI should be the vanguard. I should emphasize that I never expected to be able to send a

Re: DBI v2 - The Plan and How You Can Help

On Sat, 2005-07-09 at 12:42 +0200, Jochen Wiedmann wrote: > Jonathan Leffler wrote: > > > I dunno which DBMS support prepare without a database connection, but I > > would expect all the mainstream databases to require a database connection. > > +1 > > > I'm also far from convinced that there'

Re: DBI v2 - The Plan and How You Can Help

No - you don't seem to understand. The challenge-response protocol can ask someone for the RSA key fob number this time, their mother's maiden name the next time, their employee number the time after that, and nothing on the fourth occasion. You cannot predict what the extra information requeste

Re: DBI v2 - The Plan and How You Can Help

> driver://user:[EMAIL PROTECTED]:port/instance > I haven't been following this too closely, so my apologies if already mentioned. This connect string is very much like the new Easy Connect Naming method in Oracle 10g. eg. sqlplus scott/[EMAIL PROTECTED]:port/service Note that it is not 'ins

Re: DBI v2 - The Plan and How You Can Help

I have an additional reply to the following ... At 10:25 PM +1000 7/9/05, Adam Kennedy wrote: In any case, I still propose that DBI2 split the driver interface into Roles. The main "DBI2::Role::Transport" role does ONLY what DBI does best now. That is, connecting to the database, preparing and

Re: DBI v2 - The Plan and How You Can Help

At 10:25 PM +1000 7/9/05, Adam Kennedy wrote: In any case, I still propose that DBI2 split the driver interface into Roles. The main "DBI2::Role::Transport" role does ONLY what DBI does best now. That is, connecting to the database, preparing and sending queries, and fetching the results. For

Re: DBI v2 - The Plan and How You Can Help

Jeffrey W. Baker skribis 2005-07-09 11:27 (-0700): > > Oh drat - not the DBI connection string discussion again! > There are certainly database-specific things to be worked around. An > improvement to the current DSN scheme would be a URI, as discussed in > the past. The leading dbi: on every DSN

Re: DBI v2 - The Plan and How You Can Help

Jonathan Leffler wrote: I dunno which DBMS support prepare without a database connection, but I would expect all the mainstream databases to require a database connection. +1 I'm also far from convinced that there's any significant benefit in separating the 'create a database handle' from t

Re: DBI v2 - The Plan and How You Can Help

On 7/9/05, Darren Duncan <[EMAIL PROTECTED]> wrote: > > At 1:22 AM -0700 7/9/05, Jonathan Leffler wrote: > >On 7/4/05, Darren Duncan <[EMAIL PROTECTED] > wrote: > >5. All details used to construct a connection handle should be > >completely decomposed rather than shoved into an ungainly "data > >s

Re: DBI v2 - The Plan and How You Can Help

On Sat, 2005-07-09 at 01:22 -0700, Jonathan Leffler wrote: > Oh drat - not the DBI connection string discussion again! > > On 7/4/05, Darren Duncan <[EMAIL PROTECTED]> wrote: > > > 5. All details used to construct a connection handle should be > > completely decomposed rather than shoved into an

Re: DBI v2 - The Plan and How You Can Help

In particular, the DBI must not mandate impossible levels of support from the drivers. It will benefit you nothing if the DBI is immaculate and wonderful and incredibly all-singing and all-dancing, but no-one can write a driver for it because the requirements cannot be met by the actual DBMS tha

Re: DBI v2 - The Plan and How You Can Help

Oh drat - not the DBI connection string discussion again! On 7/4/05, Darren Duncan <[EMAIL PROTECTED]> wrote: > 5. All details used to construct a connection handle should be > completely decomposed rather than shoved into an ungainly "data > source". Examples of what should be distinct (not all

Re: DBI v2 - The Plan and How You Can Help

Jonathan, while you are well-meaning in your comments, you are mis-reading what I have said multiple times and are therefore making a straw man argument against it. Regarding this point: >5. All details used to construct a connection handle should be completely decomposed rather than shoved

Re: DBI v2 - The Plan and How You Can Help

Jared Still wrote: I use a (Perl) password server for this. Passwords are stored encrypted in a configuration file. Clients authenticate with the server, and receive a requested password (encrypted) across the network, if the client is entitled. The user authentication is rudimentary, but it

Re: DBI v2 - The Plan and How You Can Help

Late to the ball - and only picking up on one issue... On 7/4/05, Darren Duncan <[EMAIL PROTECTED]> wrote: > 2. Always separate out any usage stages that can be performed apart > from the database itself. This allows an application to do those > stages more efficiently, consuming fewer resources

Re: DBI v2 - The Plan and How You Can Help

At 1:22 AM -0700 7/9/05, Jonathan Leffler wrote: On 7/4/05, Darren Duncan <[EMAIL PROTECTED] > wrote: 5. All details used to construct a connection handle should be completely decomposed rather than shoved into an ungainly "data source". Examples of what should be dist

Re: DBI v2 - The Plan and How You Can Help

At 1:03 AM -0700 7/9/05, Jonathan Leffler wrote: Can you explain which parts of the SQL:2003 mandate this notation? I've had a moderately good poke around my copy of ISO/IEC 9075-2:2003 (SQL/Foundation) and cannot find this. I'd like a few section numbers listed which describe this. The variou

Re: DBI v2 - The Plan and How You Can Help

Still late to the party - another one bullet point item... On 7/4/05, Darren Duncan <[EMAIL PROTECTED]> wrote: > 4. All host parameters should be named (like ":foo") rather than > positional (like "?"), meeting with the SQL:2003 standard. The named > format is a lot easier to use and flexible, ma

Re: DBI v2 - The Plan and How You Can Help

At 12:35 AM -0700 7/9/05, Jonathan Leffler wrote: I dunno which DBMS support prepare without a database connection, but I would expect all the mainstream databases to require a database connection. IBM DB2 does; IBM Informix Dynamic Server (IDS) does; someone else commented on this and said Or

Re: DBI v2 - The Plan and How You Can Help

I use a (Perl) password server for this. Passwords are stored encrypted in a configuration file. Clients authenticate with the server, and receive a requested password (encrypted) across the network, if the client is entitled. The user authentication is rudimentary, but it works. SSH certificate

Re: DBI v2 - The Plan and How You Can Help

I don't mind if you implement this ".dbi" feature though, I just want it to be invisible :) i.e. don't check this file, if I explicitly supply username and password (this is obvious, right?) and show some warnings if don't. Say, make a connect parameter "use_dot_dbi", which is zero by default.

RE: DBI v2 - The Plan and How You Can Help

Sam Vilain wrote: > Maxim Sloyko wrote: > >> But this is not the point. The point was that usage of some file with >> passwords by *DEFAULT* is not the way to go, IMHO. It raises more >> problems than it solves. > > > Can you give an example of such a problem that wasn't already there? > > J

RE: DBI v2 - The Plan and How You Can Help

When I go to the donation page and attempt to make a donation, the drop-down box does not give DBI as a valid recipient. Is it possible several people may not have donated as they noticed the same results, or maybe they did and it all went into the Perl Development Fund instead? > -Or

Re: DBI v2 - The Plan and How You Can Help

Sam Vilain wrote: Maxim Sloyko wrote: But this is not the point. The point was that usage of some file with passwords by *DEFAULT* is not the way to go, IMHO. It raises more problems than it solves. Can you give an example of such a problem that wasn't already there? Just to be clear, the

Re: DBI v2 - The Plan and How You Can Help

Maxim Sloyko wrote: But this is not the point. The point was that usage of some file with passwords by *DEFAULT* is not the way to go, IMHO. It raises more problems than it solves. Can you give an example of such a problem that wasn't already there? Just to be clear, the file would only need

Re: DBI v2 - The Plan and How You Can Help

On Wednesday 06 July 2005 06:39 am, Maxim Sloyko wrote: > But this is not the point. The point was that usage of some file with > passwords by *DEFAULT* is not the way to go, IMHO. It raises more > problems than it solves. To tack onto that, IMO it would make more sense if the password situation

Re: DBI v2 - The Plan and How You Can Help

Steve Sapovits wrote: Maxim Sloyko wrote: I don't think this solves the problem, because what I usually want is the user to be able to use the application, but unable to see the DB password. So the user should have "read" permission set for the file, but on the other hand he shouldn't. It's n

Re: DBI v2 - The Plan and How You Can Help

Maxim Sloyko wrote: I don't think this solves the problem, because what I usually want is the user to be able to use the application, but unable to see the DB password. So the user should have "read" permission set for the file, but on the other hand he shouldn't. It's not not a problem for We

Re: DBI v2 - The Plan and How You Can Help

Sam Vilain wrote: However, making it in a file in $HOME/.xxx means that the sysadmin can set it up to be mode 400 or something like that, to ensure other users can't access it if someone forgot to set the permissions right on the application code (or, hopefully, configuration file). I don't t

Re: DBI v2 - The Plan and How You Can Help

- optional treatment of the statements as an AST, similar in concept to SQL::Routine, or Tangram::Expr. Death to SQL templating systems! I suspect during this process people are going to want a lot of things that layer on top of what we currently see as DBI. Personally I think Tim got

Re: DBI v2 - The Plan and How You Can Help

At 6:14 PM +1200 7/5/05, Sam Vilain wrote: I think I'm beginning to like it. Allow me to suggest one or two further refinements... my $sth1 = $dbh.compile( $sql_or_ast ); # always sans connection $sth1.prepare(); # always with connection, even if DBD doesn't use it $sth1.execute(); # alwa

Re: DBI v2 - The Plan and How You Can Help

4. All host parameters should be named (like ":foo") rather than positional (like "?"), meeting with the SQL:2003 standard. The named format is a lot easier to use and flexible, making programmers a lot less error prone, more powerful, and particularly more resource efficient when the same par

Re: DBI v2 - The Plan and How You Can Help

Darren Duncan wrote: Okay, considering that using the same name prepare() like this may confuse some people, here is a refined solution that uses 3 methods instead; please disregard any contrary statements that I previously made: I think I'm beginning to like it. Allow me to suggest one or tw

Re: DBI v2 - The Plan and How You Can Help

Okay, considering that using the same name prepare() like this may confuse some people, here is a refined solution that uses 3 methods instead; please disregard any contrary statements that I previously made: # Opt 1: A user that wants the most control can do this (new feature): my $sth1

Re: DBI v2 - The Plan and How You Can Help

Darren Duncan wrote: 3. Redefine prepare() and execute() such that the first is expressly for activities that can be done apart from a database (and hence can also be done for a connection handle that is closed at the time) while all activities that require database interaction are deferred to

Re: DBI v2 - The Plan and How You Can Help

Richard Nuttall wrote: - support for automatically pulling database DSN information from a ~/.dbi (or similar) file. This is constantly re-invented poorly. Let's just do a connect by logical application name and let the SysAdmins sort out which DB that connects to, in a standard wa

Re: DBI v2 - The Plan and How You Can Help

Tim et al, Following are some ideas I have for the new DBI, that were thought about greatly as I was both working on Rosetta/SQL::Routine and writing Perl 6 under Pugs. These are all language-independent and should be implemented at the Parrot-DBI level for all Parrot-hosted languages to tak

Re: DBI v2 - The Plan and How You Can Help

Richard Nuttall wrote: - support for automatically pulling database DSN information from a ~/.dbi (or similar) file. This is constantly re-invented poorly. Let's just do a connect by logical application name and let the SysAdmins sort out which DB that connects to, in a standard

Re: DBI v2 - The Plan and How You Can Help

- support for automatically pulling database DSN information from a ~/.dbi (or similar) file. This is constantly re-invented poorly. Let's just do a connect by logical application name and let the SysAdmins sort out which DB that connects to, in a standard way. This reminds me o

Re: DBI v2 - The Plan and How You Can Help

Hey Tim. > I've kept an eye on Perl 6 and Parrot developments but I'm no expert in > either. What I'd like *you* to do is make proposals (ideally fairly > detailed proposals, but vague ideas are okay) for what a Perl 6 DBI API > should look like. > Keep in mind that the role of the DBI is to prov