Michael G Schwern wrote: > Note that the test I pasted has an extra line: > > is $bt->sheep, 2, 'sheep bursting violently'; > > The CDBI test suite does not have that line. It just checks that it got an > object, not that it contains the right data. CDBI does not set $bt->sheep to > 2 when you pass sheep => 2 into insert(), so neither should CDBICompat.
I'm sorry, I was careless in what I wrote. As I said, I get confused by
the test infrastructure and environment etc so what I actually did was
to extract the code and data that we care about into a stand-alone
program. It's a bit messy because of print statements etc to convince
myself about what I see and backward-incompatibility method name
changes. But it runs under CDBI 3.017 and 0.96 and gives the same
result, which is that sheep is 2 after the insert. I've attached the code.
> So maybe you're talking about some other problem?
>
> To relieve any confusion, I've attached the patch I wrote against the CDBI
> 3.0.17 test suite so you can try it out.
I think the confusion is probably caused by the test structure and the
somewhat bizarre behaviour of CDBI in some edge cases. If you step
through the test with the debugger and some means of inspecting the
database[1] you'll see that CDBI *does* insert the record correctly
using the renamed accessor. What fails is the subsequent object population.
After creating the new record, insert() discards all columns except
Primary, to maintain consistency between the ORM and the database. When
the value of a column like 'sheep' is subsequently wanted, CDBI rereads
it from the database.
Unfortunately the test schema for the Movies table is not valid, since
the declared Primary key 'title' is not a unique key. And it seems that
CDBI silently selects the first row if there are multiple matches rather
than highlighting the problem. Thus the object returned by insert()
comes to refer to a different row in the database.
> What, exactly, is the feature you're testing? Maybe if you demonstrated it as
> a patch to CDBI 3.0.17 things will be clearer for me.
As I say, I use renamed accessors heavily in my CDBI code so that is
what I care about. The basis of my concern is that I have applications
that work under CDBI and don't work under CDBICompat and my
investigation led me to believe it is inconsistencies with accessor
renaming that are the source of my problem.
Cheers, Dave
[1] There's probably a better way but I used:
use Data::Dumper;
Film->set_sql(dump => 'SELECT * FROM Movies');
sub dump_movies {
my $sth = Film->sql_dump;
$sth->execute;
warn Dumper($sth->fetchall_arrayref({}));
}
exploding-sheep.pl
Description: Perl program
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
