| 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> |
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