[DBIx-Class-Devel] SQL::Statement-based driver support

Brendan Byrd Perl at ResonatorSoft.org
Thu Mar 21 13:10:46 GMT 2013


On Thu, Mar 21, 2013 at 5:59 AM, Peter Rabbitson <rabbit+dbic at rabbit.us>wro=
te:

>
> If you had the results would be green ;) You got confused by the
> interlaced log of 32 concurrent cpanm workers, though if you
> look closely the problem is obvious. Cherry-pick 10e248bf59 and
> resmoke - the problem will become clearer.


Actually, the debug log spam is confusing enough to confuse Travis itself:

https://www.travis-ci.org/dbsrgits/dbix-class/builds/5661989

After 5000 lines of log, it gives up and gives me that log.txt link above.
 Even there, I don't see any actual tests ran.  It's just a mess of cpanm
spam.

Okay, I see the FAILED line, and -eventually- found the BerkeleyDB fatal
error line, but man, that is a buried mess. There's got to be a good
compromise between multi-threaded speed and logging sanity. Maybe if they
all wrote different log files and if one of them errored, that STDERR thing
would only show that log?

(Sigh, that's what 10e248bf59 is for...  Also, I like the comments.)

Someday, I'll parse though your Travis YML file and stuff some of that into
Dist::Zilla::TravisCI. You do have some good work there worth sharing.


> Because of the dq transition you don't want to reimplement, you want to
> wrap. Producing a separate "inlining" dialect for what is effectively a
> bug does not sound right from an architectural standpoint, hence the
> "wrap it later approach. Yes it is heavier from CPU standpoint, but it
> clearly delineates what is "the implementation" and what is "bug
> workaround crap we want to throw away or enclose in a version check
> role".


Per MST's advice, I'm going to create a DQ branch for this work, anyway, to
make the Oracle-based JOINs more sane.  I'll have to see how different
SQLMaker looks for that.  It looks like $work is picking up, so it might be
a few weeks.


> > Oh, you're talking about the _dbh_last_insert_id exception.  How far ba=
ck
> > should it go?  SQLMaker level?
>
> No, ::Storage::X::insert() level. Before we even *go* to the DBD.


Okay, I'll probably auto-detect the logic for resorting to
_dbh_last_insert_id the same way Storage::DBI::insert() handles it, before
actually next::method into insert().  It'll also do a
$dbi->can('last_insert_id') check, since some drivers (like mine) might
actually have the foresight to implement such a method.

-- =

Brendan Byrd <Perl at ResonatorSoft.org>
Brendan Byrd <BBYRD at CPAN.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class-devel/attachments/201303=
21/44644684/attachment.htm


More information about the DBIx-Class-Devel mailing list