decided to require 5.10.0+ or something else
newer than 5.8.x then I would likely follow suit. I don't actually need any
Perl features newer than what 5.8.0 provides, but I would leverage some for
cleaner coding if they were available.
Thank you for any insight.
-- Darren Duncan
-compatible and not the
breaking version. -- Darren Duncan
On 2019-01-17 2:43 AM, p...@cpan.org wrote:
On Thursday 17 January 2019 11:06:22 Alexander Hartmaier wrote:
I'm aware of that, semantic versioning and major versions exist to handle API
breakage.
Such thing is unsupported by CPAN clients. So
behavior is toggled on a per-connection switch)
is actually the best and most elegant solution for satisfying all parties under
the assumption that there are savvy developers who fully understand the problem
and are able and willing to support such a more-complicated codebase.
-- Darren Duncan
the MariaDB name as that sends the wrong message.
Keeping the MySQL name says its for all the (API-compatible) forks while using
the MariaDB name implies that the MariaDB fork is more special than the others.
-- Darren Duncan
Michael, why can't you accept moving forward under a new module name? Why does
it have to be under the old name? When people purposefully want to upgrade they
purposefully choose the new module name in order to do so. What is the actual
problem in that? -- Darren Duncan
On 2017-11-09 10:59
ewer words. Do
all new development under a new name, including all of Pali's work, and leave
the current name for a product with no further effort applied to develop it. --
Darren Duncan
Duncan
On 2017-11-09 12:54 AM, p...@cpan.org wrote:
On Tuesday 07 November 2017 13:19:23 Darren Duncan wrote:
A maintenance branch would exist starting from the 4.041/3 release on which
further stable releases named DBD::mysql 4.x would be made, and the primary
goal of this branch is to not break
On 2017-11-09 12:54 AM, p...@cpan.org wrote:
On Tuesday 07 November 2017 13:19:23 Darren Duncan wrote:
The whole discussion on the mailing lists that I recall and participated in
seemed to consensus on branching DBD::sqlite in order to best satisfy
this, instead having internal logic or their own toggle to work
with DBD::mysql vs DBD::mysql2, or a few may branch, but the key thing is that
branching DBD::mysql does NOT necessitate doing so in the rest of the ecosystem.
-- Darren Duncan
On 2017-11-07 12:07 PM, Night Light wrote:
Proposed
s, I will get
those.)
-- Darren Duncan
On 2017-11-07 3:41 AM, Night Light wrote:
For the reason of "silence":
I've spoken to other users to hear that they have passively withdrawn from this
discussion as they are not motivated to be part of a release where concerns
about backwards
will introduce corruption simply for upgrading.
-- Darren Duncan
On 2017-09-19 5:46 AM, Night Light wrote:
Dear Perl gurus,
This is my first post. I'm using Perl with great joy, and I'd like to express my
gratitude for all you are doing to keep Perl stable and fun to use.
I'd like to ask
for the most complicated aspects of Unicode, they can avoid 99% of the
complexity.
-- Darren Duncan
Unicode
handling with text don't inadvertently break blob handling. -- Darren Duncan
On 2017-09-13 6:31 AM, p...@cpan.org wrote:
On Tuesday 12 September 2017 11:32:36 Darren Duncan wrote:
Regardless, following point 2, mandate that all Git pull requests are made
against the new 5.x master; the 4.x legacy branch would have no commits
except minimal back-porting.
New pull
short of hard requiring
the new version.
Basically, its all about tradeoffs, who you want to do what work and who you
want to be able to do zero work.
-- Darren Duncan
On 2017-09-12 11:05 AM, p...@cpan.org wrote:
On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote:
I strongly recommend that another thing happen, which is
re-versioning DBD::mysql to 5.0.
1. From now on, DBD::mysql versions 4.x would essentially be frozen
at 4.041/4.043.
2. From now
and Pali and others, what think of my proposal?
-- Darren Duncan
On 2017-08-28 12:00 PM, Alexander Foken wrote:
On 28.08.2017 18:19, Darren Duncan wrote:
While a fork may be the best short term fix, as keeping up with security
issues is important, ...
Not being able to connect to MySQL / MariaDB from Perl is not acceptable. Having
tons of known bugs
is there.
I'd say move all your MySQL projects to Pg and then you won't have to think
about MySQL anymore. Its not just about the Perl driver, but the differences in
quality/features/etc of the DBMSs themselves. -- Darren Duncan
s a work in progress and there is cross-influence between DBP and other
projects in the Muldis organization.
I'm still a few weeks away from announcing executing code here.
-- Darren Duncan
ference implementation and fleshed out
documentation, which will hopefully be within a month.
-- Darren Duncan
Database Abstraction Specification
* DAR - Database Abstraction Role
* DIR - Database Interface Role
* DR - Database Role
* Duncan's Database Role (DDR)
In any case, great idea for doing this PSGI-style.
-- Darren Duncan
endencies, in contrast to "DBI" being a
mandatory shared dependency now in Perl 5. No mandatory dependencies includes
no Perl 6 roles that must be consumed in order to declare provision of the API.
-- Darren Duncan
On 2016-12-08 3:05 PM, Tim Bunce wrote:
On Wed, Nov 23, 2016
essage, and other details are pending.
Does this sound like a proposal you can get behind, is it okay to use "DBI" for
the name reserved for the specification (occupied by POD files say but no code),
do you have any questions or counter-proposals, and so on? Also, when this
proposal is adopted in Perl 5, what namespace should it have?
Thank you in advance.
-- Darren Duncan
, or otherwise it
could just help inform your proposal.
-- Darren Duncan
A discussion started on dbi-users which I thought seemed more appropriate to
continue on dbi-dev assuming it caries on in the direction of a design
discussion. I have quoted the important parts of each original message below,
to get it started. -- Darren Duncan
Forwarded Message
that sentence I had thought you added support for
parsing SQL stored procedures/functions. Oh well. -- Darren Duncan
where ever possible. In such cases there is no distinction between file based
and not.
-- Darren Duncan
their different syntax or
capabilities.
5. Some other option?
Thanks in advance for the info.
-- Darren Duncan
Max, you can distinguish a missing column from a null one quite easily in
regular Perl. If exists $hash-{key} is false then the column doesn't exist,
where if that is true but defined $hash-{key} is false then it exists but is
null. -- Darren Duncan
On 2/10/2014, 10:57 AM, Max Maischein
On 2013.11.22 5:13 PM, David E. Wheeler wrote:
DBI Folks Gisle,
I want to add support for specifying database connections as URIs to Sqitch, my
DB change management system. I started working on it today, following the
examples of JDBC and PostgreSQL. Before I release, though, I’d like a bit
this is that DBI's uri scheme uses the same syntax for both
database even though how they're treated is actually very different. And you
don't have to do the same.
-- Darren Duncan
as
easily as installing a Perl module.
-- Darren Duncan
and installed properly, so stick with that
and don't try to do DBI 1.57. If DBI is actually installed (you did make
install) then the latest DBD::SQLite should work; if it doesn't then that's a
separate problem. -- Darren Duncan
doing all the
client work yourself anyway. -- Darren Duncan
of parsed SQL is a lot
easier. If you don't see the benefit, then never mind, and I'll come back to
you when I have an executable, hopefully soon.
-- Darren Duncan
strings to TEXT, that
would carry the best semantics.
-- Darren Duncan
On 2013.01.05 5:39 AM, Lyle wrote:
On 05/01/2013 10:41, Darren Duncan wrote:
Since the SQL standard, as well as some other programming languages, define
decimal as being exact numeric, then it is absolutely wrong to map them to
either FLOAT or DOUBLE. In fact, in Perl 5 the only native type
, which is surely
the case, then you don't have say the confusion about which things in the first
column are SQL standard actual vs some placeholder you added from ODBC/etc.
-- Darren Duncan
Lyle wrote:
Hi All,
Whilst working on another project it made sense to write a tool for
comparing
such a RAM-based DBMS if the DBI test suite
exploits this in its test suite to help test the DBI interface itself.
-- Darren Duncan
Jens Rehsack wrote:
Hi all,
I'd like to merge DBD::RAM into DBI for several reasons:
1) It's a tiny one without much dependencies, it should run fine
with just DBI
files and be able to work with them. And security is helped as it
isn't so easy for someone to DOS you by giving you a huge input.
-- Darren Duncan
Jens Rehsack wrote:
Am 11.04.2012 04:58, schrieb Darren Duncan:
That's what I would do if I were making a SQL parser. Oh wait, I am!
Just another SQL Parser? Why not taking/improving one of the
existing ones? Or is it, because they're not invented here?
No, not just another; I don't do
if I were making a SQL parser. Oh wait, I am!
-- Darren Duncan
, and this is
an example others can follow.
-- Darren Duncan
another version of Oraperl itself again.
Then you don't have to think about deprecation of Oraperl so much as deprecation
of DBD::Oracle features that Oraperl depends on, which is much less likely since
other things probably use those features too.
-- Darren Duncan
to Database Systems that sold over 800K copies), and one of his
latest co-authored books in 2010 explicitly covers part of my project with a
chapter.
-- Darren Duncan
Brendan Byrd wrote:
On Fri, Sep 23, 2011 at 5:01 PM, Darren Duncan dar...@darrenduncan.net wrote:
This essentially is exactly what you want to do, have a common query
syntax where behind the scenes some is turned into SQL that is
pushed to back-end DBMSs, and some of which is turned
.
-- Darren Duncan
Brendan Byrd wrote:
Okay, this is a big blue sky idea, but like all things open-source, it comes
out of a need. I'm trying to merge together Excel (or CSV), Oracle, Fusion
Tables, JSON, and SNMP for various data points and outputs. DBIC seems to
work great for a large database
never abstracted these away; it just prevents the need for some other kinds of
DBMS-specific hacks.
-- Darren Duncan
Tim Bunce wrote:
On Mon, Sep 12, 2011 at 01:13:58PM -0700, Darren Duncan wrote:
To be brief, ...
Darren, if you want to do something really directly useful for the DBI
ecosystem I would encorage you (or anyone else) to work on creating a
DBI test suite that's independent of the DBI
query what version(s) of the DBI spec
the DBD provides.
So what say you?
-- Darren Duncan
other kinds of changes to a minimum, to aid transition, and then other API
changes can happen later, with new API versions.
-- Darren Duncan
Darren Duncan wrote:
To be brief, ...
I don't know if this has come up in past discussions about the next
major DBI version, but I'll say it now, since
checking all available packages on the system, well that solution
could also exist as said external DBI utility function.
-- Darren Duncan
David Nicol wrote:
On Mon, Sep 12, 2011 at 3:13 PM, Darren Duncan dar...@darrenduncan.net wrote:
So what say you?
I think you can do this without any change to DBI.
You have your own DBI-like framework; you could declare that anything
that passes your conformance suite
is compliant
David Nicol wrote:
On Mon, Sep 12, 2011 at 5:20 PM, Darren Duncan dar...@darrenduncan.net wrote:
How mandatory, currently, is the mandatory shared codebase? Are
there really traps and snares preventing
a different framework from using DBD modules? I'm presuming that there
aren't; ICBW.
So
can choose to create a new DBD that just works the
new/inverted way, and users can use that and legacy DBDs at the same time.
-- Darren Duncan
with trans-ASCII
characters, we have to account for those too, making sure that the various
Perl-side code correctly matches or doesn't match those identifiers, and so on.
-- Darren Duncan
Is it necessary for each DBI driver to have a prefix registered in DBI itself,
or is this only necessary when the driver wishes to expose extra public methods?
If the DBD doesn't expose custom methods, can it be used without the prefix
registration? -- Darren Duncan
Rudy Lippan wrote:
On 11/03/2010 10:08 PM, Darren Duncan wrote:
Darren Duncan wrote:
Rudy Lippan wrote:
Does anyone know if there are any DBD::drivers that do not use some
variant of SQL? I ask because I am planing on implementing the driver
using mongoDB's native query language initially
query language initially as per
your plan. If the ability to query in SQL is desired then you can provide that
as an alternative, but under no circumstances should the ability to use the
DBMS' native query language be denied as an option to users.
-- Darren Duncan
Darren Duncan wrote:
Rudy Lippan wrote:
Does anyone know if there are any DBD::drivers that do not use some
variant of SQL? I ask because I am planing on implementing the driver
using mongoDB's native query language initially, but having a
query_language attribute so that It would be possible
to be the case.
Guidance please. Thank you.
-- Darren Duncan
Tim Bunce wrote:
Short version:
Please download build test *and install* DBI 1.613_71, then download build
and test any compiled drivers you use to check they work with DBI 1.613_71.
Let us know about any failures *and* successes
it much easier to test that drivers are correct if DBI
isn't muddling things up by perpetuating the pollution. -- Darren Duncan
Tim Bunce wrote:
What's the state of play?
Will DBI 1.614 still lack the POLLUTE or did you put that back in? -- Darren
Duncan
like the fix should be some relatively simple symbol renaming.
I could probably do this, but not until at least a few days from now when I have
more time to do that *and* test it.
-- Darren Duncan
updateable by the public; posting in the list can
cause an update there by a registered SQLite developer).
Please do not reply to me directly with your responses. Instead send them to
the forums or file with RT as is appropriate.
Thank you. -- Darren Duncan
, call it 1.613_1 or 1.613_001 or
such.
Does that not make more sense?
-- Darren Duncan
of mandating declared versions and
go from there.
-- Darren Duncan
in a local file; this file is
named by the user when connecting. I think that #2 is the best option for that.
-- Darren Duncan
with your responses. Instead send them to
the forums or file with RT as is appropriate.
Thank you. -- Darren Duncan
with your responses. Instead send them to
the forums or file with RT as is appropriate.
Thank you. -- Darren Duncan
);
SQLite also has savepoints, since 3.6.8 around January.
See http://sqlite.org/lang_savepoint.html for details.
SQLite:
SAVEPOINT $name
RELEASE [SAVEPOINT] $name
ROLLBACK [TRANSACTION] TO [SAVEPOINT] $name
Adding that to DBIx::Class shouldn't be difficult.
-- Darren Duncan
for DBI itself to use those semantics (but it hadn't already).
-- Darren Duncan
if
there are none, and commit()/rollback() ends the innermost transaction.
This all said, if you still want to have actual named savepoints, well David's
proposal sounds fairly decent.
-- Darren Duncan
David E. Wheeler wrote:
Tim et al.,
Anyone given any thought to an interface for savepoints? They're
changing nothing in DBI is actually the
best approach concerning savepoints. -- Darren Duncan
.
Please do not reply to me directly with your responses. Instead send them to
the forums or file with RT as is appropriate.
Thank you. -- Darren Duncan
::SQLite are expected to come out separately from and after the
stabilized switch to the amalgamation sources.
Please do not reply to me directly with your responses. Instead send them to
the forums or file with RT as is appropriate.
Thank you. -- Darren Duncan
, and continues to do so, I'm the happiest, but so far he
isn't. And my email attempts have failed at a response.
So, should I try to phone Matt now?
Thank you. -- Darren Duncan
Cosimo Streppone wrote:
In data 27 marzo 2009 alle ore 03:30:10, Darren Duncan
dar...@darrenduncan.net ha scritto:
So, out of my un-paid projects, my promise to take over release
management of DBD::SQLite (from the still incommunicado previous
owner) has now come to the front of my queue (now
is discussing this work so I can
join it. And I look forward to a CPAN release. Or in helping you do it.
Thank you. -- Darren Duncan
Steffen Mueller wrote:
Hi Darren, hi Matt,
Matt, I hope you're well and simply too busy to answer!
Darren Duncan wrote:
Following up a discussion a couple months ago
David E. Wheeler wrote:
On Mar 27, 2009, at 2:39 AM, Darren Duncan wrote:
I have tried emailing Matt several times without response already.
Should I try telephoning him next? For all it looks like, Matt has
abandoned the module. If someone knows better, or has been in contact
recently
on utsl.gen.nz or
github or both, so I can receive patches by pulling from someone's fork. Its
not up yet though.
Thank you in advance for any feedback.
-- Darren Duncan
DBD::SQLite. I currently
estimate mid-March to get into it.
-- Darren Duncan
Erik Aronesty wrote:
I do Perl and C and offer some help.
Same here. I feel reasonably at home both in C and Perl, and I've
written some simple XS code. I don't have any experience with DBI,
I will also do what I
.
excelent idea to use Audrey Tangs nameing convention.
I have been stuck back at 3.4 for various issues.
I do Perl and C and offer some help.
Okay and thank you.
-- Darren Duncan
of departure, but DBD::SQLite could also go the way you say. I think this
is an idea best discussed on dbi-dev or if you want to prototype and present
your idea there please do so. There are probably other issues to consider that
people may bring up.
Thank you. -- Darren Duncan
my place.
Matt, thank you in advance for a quick reply.
To everyone, please don't actually submit patches to me until I announce that
I'm ready to receive them, or just send them to RT as you already were.
-- Darren Duncan
to include in DBD::SQLite::Amalgamation if appropriate. -- Darren Duncan
Tom Browder wrote:
After looking at various modules for using SQLite, I've not found
exactly what I'm looking for. I want a pm that is higher level than
what I see in DBS::SQLite.
I would like to see functions similar to what
,
so having less indirection for implementing the language over existing
DBMSs should only be helpful. Also as commented, the solution should
support inputing or returning arbitrary configurations of data, eg,
multiple subject-to-update parameters, as SQL itself supports. -- Darren Duncan
At 3:02 PM +0100 4/27/07, Tim Bunce wrote:
You can download it from
http://homepage.mac.com/tim.bunce/.Public/perl/DBI-1.55-RC2.tar.gz
All tests of just DBI itself pass or skip on my system, Perl 5.8.8
with no threads, gcc 4.0.1, Mac OS X 10.4.9 PPC. -- Darren Duncan
of the SQL 2003
Documents zip file, linked to near the top. -- Darren Duncan
At 2:46 PM +0100 4/13/07, Tim Bunce wrote:
You can download it from
http://homepage.mac.com/tim.bunce/.Public/perl/DBI-1.55-RC1.tar.gz
DBI's make test were all successful or skipped with Perl 5.8.8,
with no threads, under Mac OS X 10.4.9. -- Darren Duncan
not actually tried to use any of the above with my own
application code, however, nor am I currently equipped to do so.
Maybe in a few months.
-- Darren Duncan
At 11:36 AM + 2/22/07, Tim Bunce wrote (off-list):
On Wed, Feb 21, 2007 at 09:22:32PM -0800, Darren Duncan wrote:
At 1
://homepage.mac.com/tim.bunce/.Public/perl/DBI-1.54-RC5.tar.gz
... as the other spelling just gets you RC4 again.
Anyway, RC5 fixes the problem for me; all tests pass.
-- Darren Duncan
At 10:13 AM + 2/17/07, Tim Bunce wrote:
On Fri, Feb 16, 2007 at 08:26:57PM -0800, Darren Duncan wrote:
A simple 'make test' fails on my machine (Perl 5.8.8 no threads, Mac
OS X 10.4.8 PPC, GCC 4.0.1) citing various problems with Gofer.
t/85gofer.
# Failed test
At 9:51 PM + 2/17/07, Tim Bunce wrote:
On Sat, Feb 17, 2007 at 03:22:14AM -0800, Darren Duncan wrote:
So I updated t/85gofer.t and re-ran 'make test'.
This time, I just showed the output of testing t/85gofer.t rather
than the whole test suite.
FYI, the Perl I ran the original DBI
they'll be portability issues with some gofer transports.
A simple 'make test' fails on my machine (Perl 5.8.8 no threads, Mac
OS X 10.4.8 PPC, GCC 4.0.1) citing various problems with Gofer.
Details appear below this email.
-- Darren Duncan
--
darren-duncans-power-mac-g4:/Volumes
At 9:17 AM + 2/2/07, Tim Bunce wrote:
On Thu, Feb 01, 2007 at 10:26:09PM -0800, Darren Duncan wrote:
install_driver(Gofer) failed: Base class package
Class::Accessor::Fast is empty. (Perhaps you need to 'use' the
module which defines that package first.)
Ah, thanks. I'd planned
.
Yup, that made a big difference. All tests pass. I did not actually
try to use it or compile any DBD against it, though. -- Darren Duncan
actually try to install DBI, and I didn't test any
DBD or programs with it.
-- Darren Duncan
present.
-- Darren Duncan
1 - 100 of 150 matches
Mail list logo
