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 I
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 to be
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 rub me
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). So
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 driver
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
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).
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
://donate.perlfoundation.org/index.pl?node=Contribution%20Infoselfund=102
-Original Message-
From: Tim Bunce [mailto:[EMAIL PROTECTED]
Sent: Friday, July 01, 2005 7:06 PM
To: perl6-language@perl.org; dbi-users@perl.org
Subject: DBI v2 - The Plan and How You Can Help
Once upon
We could have an option to do Bulk Inserts ..
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
using
-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 and How You
-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 SQL Parse Trees
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: 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
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
[ ]
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
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
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
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
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's any
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
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
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 being
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
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 ungainly
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
source.
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
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 is
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.
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
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, making
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
At 1:22 AM -0700 7/9/05, Jonathan Leffler wrote:
On 7/4/05, Darren Duncan
mailto:[EMAIL PROTECTED][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
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
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 of
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
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,
?
-Original Message-
From: Tim Bunce [mailto:[EMAIL PROTECTED]
Sent: Friday, July 01, 2005 7:06 PM
To: perl6-language@perl.org; dbi-users@perl.org
Subject: DBI v2 - The Plan and How You Can Help
Once upon a time I said:
http://groups-beta.google.com/group/perl.dbi.users/msg/caf189d
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 Web
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
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
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
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(); #
- 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
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
- 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
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
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
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
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
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
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 provide
Once upon a time I said:
http://groups-beta.google.com/group/perl.dbi.users/msg/caf189d7b404a003?dmode=sourcehl=en
and wrote
http://search.cpan.org/~timb/DBI/Roadmap.pod
which yielded:
https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Detailsselfund=102
(A little over $500 of
54 matches
Mail list logo
