Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DBIx-Class-Migration CPAN distribution.

Report information
The Basics
Id: 75394
Status: open
Priority: 0/
Queue: DBIx-Class-Migration

People
Owner: Nobody in particular
Requestors: felliott [...] virginia.edu
Cc: ribasushi [...] cpan.org
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)



Subject: weird debugging output (SV = IV(0x102458e38) at 0x102458e48)
Download (untitled) / with headers
text/plain 1.5k
Hello, I think I've tracked down the source of the weird debugging output mentioned in the FAQ. The problem is that a schema with a live database handle is being serialized into 001-auto.yml and 001-auto__VERSION.yml. When SQLT::Parser::YAML runs Load() on this file, it seems to be creating a phantom DBI object that produces the output when it gets destroyed. I was able to test this by adding the following at the end of DBICDH::DeployMethod::SQL::Translator::prepare_protoschema() use Test::More; diag "Ctrl-Z now! file is: $filename"; sleep 10; I then ran the DBIC::Migration tests, Ctrl-Z'd it when I got the message, and manually deleted the translator.parser_args.package.storage key from the file. When I did this the weird output never showed up. As for the fix.... um, I dunno. DBICDH avoids this in its tests by never calling prepare_protoschema() with a connected schema. I see four possibilities: 1. DBIC::Migration::prepare should not connect the schema before calling prepare_install() 2. DBICDH should warn or clone a schema before handing it off to SQLT::DBIC 3. SQLT::Parser::DBIC shouldn't serialize a live DBIC::Schema::Storage object 4. I am an insane person and way off base. I lean towards (3) since I can't imagine what use a serialized DBI connection would be, but I don't know any of these modules well enough to say. I'm submitting it to your bug queue, b/c I figured you would know better. I'd be happy to resubmit it somewhere else if that would be appropriate. Thank you for your code and have a great day! Cheers, Fitz
Download (untitled) / with headers
text/plain 1.9k
Wow, Your the ace! What's your choice of brew, I'll tote a six pack to the next YAPC we both attend. I do think you are onto something here. I am going to share your suspicious with the DBIC cabal and see if we can end this madness once and for all. I'll give you a shout out if we find something. John On Tue Feb 28 20:24:19 2012, felliott wrote: Show quoted text
> Hello, > > I think I've tracked down the source of the weird debugging output > mentioned in the FAQ. The problem is that a schema with a live database > handle is being serialized into 001-auto.yml and 001-auto__VERSION.yml. > When SQLT::Parser::YAML runs Load() on this file, it seems to be > creating a phantom DBI object that produces the output when it gets > destroyed. I was able to test this by adding the following at the end > of DBICDH::DeployMethod::SQL::Translator::prepare_protoschema() > > use Test::More; > diag "Ctrl-Z now! file is: $filename"; > sleep 10; > > I then ran the DBIC::Migration tests, Ctrl-Z'd it when I got the > message, and manually deleted the translator.parser_args.package.storage > key from the file. When I did this the weird output never showed up. > > As for the fix.... um, I dunno. DBICDH avoids this in its tests by never > calling prepare_protoschema() with a connected schema. I see four > possibilities: > > 1. DBIC::Migration::prepare should not connect the schema before > calling prepare_install() > > 2. DBICDH should warn or clone a schema before handing it off to SQLT::DBIC > > 3. SQLT::Parser::DBIC shouldn't serialize a live DBIC::Schema::Storage > object > > 4. I am an insane person and way off base. > > I lean towards (3) since I can't imagine what use a serialized DBI > connection would be, but I don't know any of these modules well enough > to say. I'm submitting it to your bug queue, b/c I figured you would > know better. I'd be happy to resubmit it somewhere else if that would > be appropriate. > > Thank you for your code and have a great day! > > > Cheers, > Fitz
Subject: Re: [rt.cpan.org #75394] weird debugging output (SV = IV(0x102458e38) at 0x102458e48)
Date: Wed, 29 Feb 2012 11:31:00 -0500
To: bug-DBIx-Class-Migration [...] rt.cpan.org
From: Fitz Elliott <felliott [...] virginia.edu>
Download (untitled) / with headers
text/plain 593b
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=75394 > > > Wow, > > Your the ace! What's your choice of brew, I'll tote a six pack to the next YAPC we both attend. > > I do think you are onto something here. I am going to share your suspicious with the DBIC > cabal and see if we can end this madness once and for all. I'll give you a shout out if we find > something.
Thank you! I don't think I'll be making it YAPC any time soon, but feel free to hook up yourself and the cabal for all your great work on DBIC. It and the ecosystem around it are truly amazing. Cheers, Fitz
RT-Send-CC: joel.a.berger [...] gmail.com, frioux [...] gmail.com, jjnapiork [...] cpan.org
On Tue Feb 28 20:24:19 2012, felliott wrote: Show quoted text
> Hello, > > I think I've tracked down the source of the weird debugging output > mentioned in the FAQ. The problem is that a schema with a live database > handle is being serialized into 001-auto.yml and 001-auto__VERSION.yml. > When SQLT::Parser::YAML runs Load() on this file, it seems to be > creating a phantom DBI object that produces the output when it gets > destroyed. I was able to test this by adding the following at the end > of DBICDH::DeployMethod::SQL::Translator::prepare_protoschema() > > use Test::More; > diag "Ctrl-Z now! file is: $filename"; > sleep 10; > > I then ran the DBIC::Migration tests, Ctrl-Z'd it when I got the > message, and manually deleted the translator.parser_args.package.storage > key from the file. When I did this the weird output never showed up. > > As for the fix.... um, I dunno. DBICDH avoids this in its tests by never > calling prepare_protoschema() with a connected schema. I see four > possibilities: > > 1. DBIC::Migration::prepare should not connect the schema before > calling prepare_install() > > 2. DBICDH should warn or clone a schema before handing it off to
SQLT::DBIC Show quoted text
> > 3. SQLT::Parser::DBIC shouldn't serialize a live DBIC::Schema::Storage > object > > 4. I am an insane person and way off base. > > I lean towards (3) since I can't imagine what use a serialized DBI > connection would be, but I don't know any of these modules well enough > to say. I'm submitting it to your bug queue, b/c I figured you would > know better. I'd be happy to resubmit it somewhere else if that would > be appropriate.
Your analysis and hunch were spot-on. 3) is indeed the proper place to fix it (not because it is conceptually correct, but because it is the least disruptive way). I submitted the fix for cabal review [1]. When a new version of DBIC ships including this fix, all of this crap will go away. Full description of the issue can be found here [2] Cheers [1] http://lists.scsys.co.uk/pipermail/dbix-class-devel/2013-February/000284.html [2] https://github.com/dbsrgits/dbix-class/commit/b3f891879
Bumping the dep on DBIC::DH to 0.002205 should solve the problem in this ticket entirely.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.