It looks like this fork happened some time ago, and a DBD::maria is now
needed, to keep up. Is that not what it looks like?
--
everything has to be just so or the magic won't work
On Wed, Apr 22, 2015 at 6:05 PM, Wendy G.A. van Dijk wrote:
>
> Hi Jens,
>
> You interrupted me at every 5 words I tried to explain about what was
> discussed at the consensus meetings at the QA Hackathon in Berlin. We had a
> big argument, and you never ever did let me finish the explanation.
"Crockford Encoding" could be useful, and when your short names are
Crockford Encoded, they are easier to share by people.
On Tue, May 13, 2014 at 5:11 PM, Tim Bunce wrote:
> Create short names that encode a timestamp and a fixed prefix in a
> format that's unlikely to match normal name
An annual minor maintenance version release schedule would be cool, in
my opinion.
--
Application of Porter's value chain model to the executive function
reveals that the executive process transforms the input of information
into the output of decisions.
On Wed, Sep 21, 2011 at 7:27 PM, Darren Duncan
> As for DBMS-specific hacks
Another possible approach would be a strict interface that only allows
some kind of "DBI creole" -- well, I suppose a lot of other
persistence frameworks are that, pretty much.
On Tue, Sep 13, 2011 at 2:07 AM, H.Merijn Brand wrote:
> The fact that the DBI is restrictive (or restricted) is a good thing.
> First of all most of the restrictions are based on well thoughtthrough
> decisions based on speed and use of resources. I do not have to take
> those decisions again whe
On Mon, Sep 12, 2011 at 5:20 PM, Darren Duncan 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 getting away from the "framework"
On Mon, Sep 12, 2011 at 3:13 PM, Darren Duncan wrote:
>
> So what say you?
>
> -- Darren Duncan
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, and offer low-impact patches
Show, don't tell. Also, it's a little shorter now.
BEGIN THING TO INSERT
=head3 On use of non-C SQL in C methods
While some drivers support statements other than C in the
above-listed convenience functions, others do not: driver support for this
facility is not defined by the DBI interface stand
On Wed, Jun 29, 2011 at 3:02 AM, Martin J. Evans
wrote:
>> BEGIN THING TO INSERT
>> =head3 On use of non-C SQL in C methods
>>
>> When you really don't know if the statement you have in a
>> variable is going
>> to be a C or not, unrolling the process into
>> C,C, and
>> a C called within a
On Sat, Jun 11, 2011 at 12:51 PM, Tim Bunce wrote:
> Patch welcome.
>
> Tim.
here's a revised new paragraph, to go right before the =head3 C.
BEGIN THING TO INSERT
=head3 On use of non-C SQL in C methods
While some drivers support statements other than C in the above-listed
convenience functi
Thanks-- the proposed docpatch was a trial balloon to get this answer.
Here's copy for a revised proposed patch:
When you really don't know if the statement you have in a variable is going
to be a C or not, unrolling the process into C,C,
and some C variant called within an C block will always
Otherwise,
... and some fetch variant called within an C block ...
> +=head3 On use of non-C SQL in C methods
> +
> +While some drivers support statements other than C in the
> above-listed
> +convenience functions, others do not. Requirement of this facility is
> not defined
> +by the DBI int
I'm not 100% sure about the assertion about calling fetch on an
executed non-select statement handle being defined to reliably return
false, as in no-more-data as part of the standard. If C isn't
really defined to behave the same with a non-SELECT as with a SELECT
that simply doesn't return any row
in my opinion this facility should be formally defined as "undefined" and a
note should go in the selectall* docs recommending "do" instead for
non-select SQL.
A non-fatal warning is the right thing here.
do nothing |warn |die
notifies in new dev no | yes | yes
darkpan safeyes | probably |no
--
"This is not a 'bug'. Being
On Tue, Jan 18, 2011 at 6:40 AM, John Scoles wrote:
> To get the extra info that comes out in a non-DBD specific array_execute we
> would have to build in an extra iteration over the results to give a count
> of the Failed/Pass. As some of my customers use this with batch loads of
> 5meg plus o
On Mon, Jan 3, 2011 at 8:56 AM, Martin J. Evans
> I did think of one spolier which I forgot to mention. Currently DBI allows
>
> prepare($sql, {ChopBlanks => 1});
>
> and ChopBlanks is ignored silently so if you wrote code which understood
> this and moved to another machine where DBI did not, it w
On Mon, Jun 7, 2010 at 2:52 PM, H.Merijn Brand wrote:
> Consistency is VERY high in my goals, so IMHO we
> should stick to en_EN for DBI.
Why? What real problem does lack of style consistency cause? To my
mind, this standardization effort pern't do anything useful.
English is diverse.
Maybe th
On Tue, Oct 27, 2009 at 2:50 PM, David E. Wheeler wrote:
>> Ideally I'd like to see an abstract interface for managing callbacks,
>> rather than the current "stuff it in a hash". That way future support
>> for post-method callbacks and multi-callbacks per method and handle
>> could be added withou
with a new "prepare_inline" command, variable names appearing in the
statement text are magically bound at execute time.
There might be better ways to do this, but the attached appears to work.
--
"Refusing to move when ordered, he was tragically mulched." -- The Onion
DBIx-bind_param_inline-0
can your bot explain the different kinds of JOIN?
On Thu, Aug 21, 2008 at 4:06 AM, H.Merijn Brand <[EMAIL PROTECTED]> wrote:
> I'm now on irc.perl.org #dbi (alone with my bot)
> Has there ever been interrest in DBI related IRC? Is there another
> place, or are discussions deliberately restricted t
enjoy
--
David L Nicol
A room without books is perfect for watching television
> Tim.
>
> On Thu, Nov 03, 2005 at 01:24:21PM -0600, David Nicol wrote:
> > > "'connect.cached.new' => [\&pre, \&post]" syntax so that I could do
> >
> > If I understand correctly, the QPSMTPD people have just implemented
> >
> "'connect.cached.new' => [\&pre, \&post]" syntax so that I could do
If I understand correctly, the QPSMTPD people have just implemented
self-registering
callbacks in modules by standardizing the names of the callbacks and
letting package
introspection find them all. The names are hook_* where *
On 11/1/05, Dean Arnold <[EMAIL PROTECTED]> wrote:
> Er, care to refresh our collective memories w/ the executive
> overview of what "callbacks" is ?
It may amuse:
I was once doing telecommuting mod_perl development
and was tasked with "get the callbacks working" -- they were talking
about their
Dean Arnold wrote:
> I'd appreciate any reviews of my current
> DBIx::Threaded design as outlined at
> http://www.presicient.com/dbixthrd
>
> I've already implemented most of it, and have begun
> testing, but I'd like a bit more feedback before
> I rollout RC1. If you see something thats broken,
>
I have uploaded asynchronous::universal::ready and
asynchronous::universal::set_callback
to CPAN. They are both entirely trivial packages with a mess of
documentation. The
idea behind them is to support asynchonous frameworks in which the
immediate result
of passing away a message is a placeholde
On 7/5/05, Dean Arnold <[EMAIL PROTECTED]> wrote:
>
> I'm already implementing [a message-passing async] wrapper for DBI
> (DBIx::Threaded); not a pragma, and very specific to DBIv1, but hopefully it
> solves
> at least 85-90% of the problem. (tho async cancel/abort isn't
> solvable at this point
On 7/2/05, Dean Arnold <[EMAIL PROTECTED]> wrote:
> >
> > - Asynchronous queries (coroutines? threads?)
>
> Threads. If you've ever done much Java/JDBC work, you'll
> realize how much simpler a solution to async it is.
> (Ignoring the rest of Java/JDBC's undesirable traits)
A couple quarters
On Wed, 9 Mar 2005 19:34:51 -0800, Jonathan Leffler
<[EMAIL PROTECTED]> wrote:
> every statement. Besides, I can't stop userrs from using $dbh->do()
> to execute BEGIN WORK, COMMIT WORK or ROLLBACK WORK. Or from
> preparing and executing them.
there's an idea -- restrict what is allowed in $dbh
8:28 -0800, Jonathan Leffler
<[EMAIL PROTECTED]> wrote:
> On Thu, 13 Jan 2005 13:26:31 +0100, Jochen Wiedmann
> <[EMAIL PROTECTED]> wrote:
> > On Thu, 13 Jan 2005 00:40:49 -0600, David Nicol <[EMAIL PROTECTED]> wrote:
> >
> > > Am I missing something?
> >
> > That's what DBI wrappers do, and I have one of those too. But my DBI
> > wrapper reads its connection information for each "logical" data source from
> > a hash. Then there's a build_dsn() method that assembles the pieces
> > according to the name of the driver.
> >
> > If each DBD did that f
e:
> On Fri, Sep 10, 2004 at 03:15:38AM -0500, David Nicol wrote:
> > Should I set up an asynchronous DBI mailing list for discussion of
> > asynchronous DBI
> > or should discussion continue here on dbi-dev? (now I'm talking crazy)
>
> Here. But...
>
> &g
What happens if you postpend a null character?
my $zero = "0\0";
On Thu, 09 Sep 2004 09:51:37 -0400, Steven Lembark <[EMAIL PROTECTED]> wrote:
>
> Given a decent way of getting the stringy behavior (and
> a flag of SvPOK vs. SvINOK would work) I could easly write
> DBIx::PlaceHolderFill to
I was not aware of the risk of select hanging due to a signal coming in before
select can set its timer. Has anyone on this list ever been bitten by such a
thing? Is Perl vulnerable to this situation or is it taken care of
internally? The
situation described would turn a nonblocking select call
t; On Wed, 8 Sep 2004 14:39:45 -0500, David Nicol <[EMAIL PROTECTED]> wrote:
> > Right. And when your driver is providing a DBI interface to one of
> > them, to provide
> > a fileno() function that works, you may need to open a pipe and write
> > to one end
Changes: fetchavail_arrayref is retracted from the proposal.
On Thu, 2004-09-02 at 18:24, Jonathan Leffler wrote:
> On Thu, 2 Sep 2004 23:31:22 +0100, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > On Thu, Sep 02, 2004 at 01:52:59PM +0100, Matt Sergeant wrote:
> > > On 1 S
On Sat, 2004-08-28 at 06:01, Matt Sergeant wrote:
> As an addition to this thread, I just wanted to add that having each
> DBD implement their own event loop (via select() or otherwise) is not
> acceptable. Anyone who has done event driven programming will
> understand the mantra: There can be o
type when $attr{Timeout} exists.
no threads:
Include all currently pending operations on all handles of this type
of database in a set that is checked whenever ready() is called on
a pending object.
threads:
launch a thread with each statement handle. The thread responds to
incoming socket data by writing it into a buffer, and when there
is enough there, the thread sets the statement's ready attribute. All
ready() has to do is return the ready attribute.
David Nicol
gt;fetchall_arrayref});
$sth->more; # true or false -- is there more?
}
}
...
$CheeseEngine = Cheeselister;
while($CheeseEngine()){
... # do something else while we wait
}
print "\nThat's all folks!\n";
Does that match other people's thoughts on what nonblocking mode
should look like?
David Nicol
41 matches
Mail list logo
