Skip Menu |
 

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

Report information
The Basics
Id: 93976
Status: patched
Priority: 0/
Queue: DBIx-Class

People
Owner: ribasushi [...] leporine.io
Requestors: post [...] daniel-boehmer.de
Cc:
AdminCc:

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



Subject: Order of arguments to load_components matters and makes InflateColumn::DateTime stop working
Date: Tue, 18 Mar 2014 16:50:34 +0100
To: bug-DBIx-Class [...] rt.cpan.org
From: Daniel Böhmer <post [...] daniel-boehmer.de>
Download (untitled) / with headers
text/plain 2.1k
Hello everyone, I am using a common base class MyApp::Schema::Result to call __PACKAGE__->load_components. Although I couldn't find any hint that is intended behaviour or a known bug, I found out that the order of components given to load_components does matter. These are the 3 components that I load: TimeStamp InflateColumn::DateTime FilterColumn Originially I had them in alphabetical order what DOES NOT WORK: * InflateColumn::DateTime * FilterColumn * TimeStamp I tried all possible orders and it seems to be that the code is broken if FilterColumn is listed before TimeStamp. The position of InflateColumn::DateTime doesn't matter at all. That's really strange: the order of 2 modules makes another one not work?! Unfortunately I can't tell if only InflateColumn::DateTime or all components break because the broken part of my application and my test code only use the InflateColumn::DateTime. ######### This is the table from my test app: package MyApp::Schema::Result::MyTable; use strict; use warnings; use Moose; use MooseX::MarkAsMethods autoclean => 1; extends 'MyApp::Schema::Result'; __PACKAGE__->table("my_table"); __PACKAGE__->add_columns( id => {data_type => "integer", is_auto_increment => 1}, date => {data_type => "date", is_nullable => 1}, ); __PACKAGE__->set_primary_key("id"); __PACKAGE__->meta->make_immutable; 1; ######## this is the code to test the table class: #!/usr/bin/perl use MyApp::Schema; use Test::More; my $schema = MyApp::Schema->connect('dbi:SQLite:myapp.sqlite'); $schema->deploy({add_drop_table => 1}); $schema->populate(MyTable => [ {date => '1970-01-01'}, {date => '2013-12-31'}, ]); my $date = $schema->resultset('MyTable')->oldest->date; isa_ok($date, 'DateTime'); done_testing; I am using DBIx::Class 0.08270 which seems to be the current one from CPAN. Can anybody reproduce the problem? Does anyone have any hints how to track down the problem or solve it? At least, if it turns out this is expected behavior or currently not fixable, I'd like to see a hint in the documentation to any of these modules (given I have not missed it). Kind regards Daniel -- Daniel Böhmer, Diplominformatiker (BA) Freelance Software Developer
Download (untitled) / with headers
text/plain 1019b
On Tue Mar 18 16:50:50 2014, post@daniel-boehmer.de wrote: Show quoted text
> Hello everyone, > > I am using a common base class MyApp::Schema::Result to call > __PACKAGE__->load_components. > > Although I couldn't find any hint that is intended behaviour or a known > bug, I found out > that the order of components given to load_components does matter. > > These are the 3 components that I load: > TimeStamp > InflateColumn::DateTime > FilterColumn > > Originially I had them in alphabetical order what DOES NOT WORK: > * InflateColumn::DateTime > * FilterColumn > * TimeStamp > > I tried all possible orders and it seems to be that the code is broken > if FilterColumn is > listed before TimeStamp. The position of InflateColumn::DateTime doesn't > matter at all. > That's really strange: the order of 2 modules makes another one not > work?! >
Sorry for the *really* delayed reply. Could you please recall what was the perl version under which this issue was observed? Was it 5.8.something by any chance? Thank you!
Subject: [rt.cpan.org #93976]
Date: Tue, 12 Jul 2016 11:01:21 -0500
To: bug-DBIx-Class [...] rt.cpan.org
From: "Webb, David" <david.webb [...] blishmize.com>
Download (untitled) / with headers
text/plain 388b
I'm not the original reporter, but this may be related. I've found that order does matter with FilterColumn. Loading FilterColumn before InflateColumn::DateTime prevents dates from from being properly inflated and causes error when you try to treat them as DateTime objects. Loading InflateColumn::DateTime first works as expected. This occurs under Strawberry Perl 5.22.2. David Webb
Download (untitled) / with headers
text/plain 782b
On Tue Jul 12 18:01:35 2016, david.webb@blishmize.com wrote: Show quoted text
> I'm not the original reporter, but this may be related. > > I've found that order does matter with FilterColumn. Loading FilterColumn > before InflateColumn::DateTime prevents dates from from being properly > inflated and causes error when you try to treat them as DateTime objects. > Loading InflateColumn::DateTime first works as expected. > > This occurs under Strawberry Perl 5.22.2. >
Hm... I certainly do believe you, but a cursory look through what I know about the problem does not give me an easy answer... Is it possible for you to put together some sort of repro-case? It doesn't matter how complex/minimal it is - as long as it is something I can run myself and observe the problem. Thanks in advance!
Reproduction on any perl version (not just 5.8, many thanks to David Webb): perl -e ' use warnings; use strict; use Devel::Dwarn; { package Some::BaseResult; use base "DBIx::Class::Core"; # this works #__PACKAGE__->load_components(qw( InflateColumn::DateTime FilterColumn )); # this does not __PACKAGE__->load_components(qw( FilterColumn InflateColumn::DateTime )); } { package Some::Result; use base "Some::BaseResult"; __PACKAGE__->table("sometable"); __PACKAGE__->add_columns( somecolumn => { data_type => "datetime" }, ); } Ddie [ Some::Result->result_source_instance->column_info("somecolumn") ]; ' This will be fixed before 0.0829xx (most of infrastructure is already in place).
RT-Send-CC: david.webb [...] blishmize.com
Download (untitled) / with headers
text/plain 359b
On Tue Jul 12 19:55:47 2016, RIBASUSHI wrote: Show quoted text
> Reproduction on any perl version (not just 5.8, many thanks to David > Webb):
And now fixed by emitting a warning as per https://github.com/dbsrgits/dbix-class/commit/12e7015a#diff-2751ab15670aa2a17b874bc174263d24R44, instructing you what to do. Sorry it took a while, devrel including this upcoming shortly.


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.