I have a little more information now. It appears that the new version is
checking against the columns of the underlying table from which the
particular record happens to have been selected, rather than the columns
of the virtual view. Since the columns have been renamed using AS in the
SQL, that doesn't work, and in the case of this particular column, it is
defined as a literal in the SQL anyway and doesn't exist in any
underlying table.
That new behaviour seems broken in my use case, but I certainly don't
understand enough about the other use cases that this change was
designed to support to even begin to suggest how it might be fixed. In
my case, it needs to check column definitions against those declared in
my [virtual view] class, not against the columns in the underlying
tables, which could be anything.
Should I file a bug report? I don't [yet] have a simple test case.
Apologies for top posting, it seems that this post sort of starts a new
conversation, connected with my problem which is described just below.
Cheers, Dave
On 2016-01-21 11:03, Dave Howorth wrote:
On 2016-01-20 18:21, Lasse Makholm wrote:
On Wed, Jan 20, 2016 at 4:32 PM, Dave Howorth
<dhowo...@mrc-lmb.cam.ac.uk>
wrote:
I have various applications that use DBIx::Class. I just moved one of
them, which has been running OK for quite a while, to a new machine and
that meant it got a new environment, including an updated
DBIx::Class. It
no longer runs, and it would help me to try to understand what is
broken in
my own code if I could understand how the DBIC code works and why it
was
changed. If anybody could give me any pointers, I'd be grateful.
My code is dying with the error message:
DBIx::Class::Row::store_column(): No such column '_type' on
TDB::Schema::Result::Node
This appears to be caused by a change in the code in
DBIx::Class::Row in
store_column() in particular where
$self->throw_exception( "No such column '${column}'" )
unless exists $self->{_column_data}{$column} ||
$self->has_column($column);
has been replaced by
$self->throw_exception( "No such column '${column}' on " . ref
$self )
unless exists $self->{_column_data}{$column} ||
$self->result_source->has_column($column);
If I put back the original code there, my application appears to work.
Now my TDB::Schema::Result::Node contains some gnarly code that it will
take me some time to regain familiarity with, and I think it would
help me
if I understood why that change had been made in DBIx::Class::Row so I
might get some idea of what I need to change in my own code.
If anybody can point me to the change or provide any explanation, I'd
appreciate it.
https://github.com/dbsrgits/dbix-class/commit/4006691d207a6c257012c4b9a07d674b211349b0
Without knowing what I'm talking about, this would seem to only
matter if
you do something funky like dynamically re-blessing result objects...
Does TDB::Schema::Result::Node and the underlying table actually have a
_type column?
/L
Many thanks Lasse,
The class is a virtual view. It's data comes from a union over a bunch
of tables but yes it does have a _type column.
I've reproduced the commit log entry below. I obviously haven't had
enough coffee this morning because I still haven't worked out what an
'rsrc' is. And sadly I don't understand how the whole view/result
source/result/row thing is implemented. I haven't found anything in
the POD yet that shows me what I may have done wrong, so I guess I
have some careful reading and code reading to come. I've reproduced
the relevant bits of the class below as well in case anybody can spot
a missing call or bad arguments etc.
Cheers, Dave
Avoid ResultSourceProxy calls whenever possible
Along with efficiency gains this commit makes a very subtle but crucially
important change: From here now on when we operate on an instance, we are
guaranteed to query this instance's result source. The previous codepaths
would nearly randomly switch between the current rsrc instance and the
one
registered with the corresponding result class.
package TDB::Schema::Result::Node;
use parent 'DBIx::Class::Core';
__PACKAGE__->table_class('DBIx::Class::ResultSource::View');
__PACKAGE__->table('nodes');
__PACKAGE__->result_source_instance->is_virtual(1);
my $test_db_view =
"SELECT
sp_id AS id,
sp_name COLLATE latin1_general_ci AS _name,
sp_comment COLLATE latin1_general_ci AS _comment,
sp_status COLLATE latin1_general_ci AS status,
'species' COLLATE latin1_general_ci AS _type,
old_sp_id AS old_sunid,
pr_id AS parent_id
FROM species
UNION ALL
... other similar selects for other tables ...
";
__PACKAGE__->result_source_instance->view_definition($test_db_view);
__PACKAGE__->add_columns(
id => {
data_type => 'mediumint',
is_nullable => 0,
},
... other columns ...
_type => {
data_type => 'text',
is_nullable => 0,
},
);
__PACKAGE__->set_primary_key('id');
Cheers, Dave
PS The old version says it is '0.08200' and the new is '0.082820'.
_______________________________________________
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/dbix-class@lists.scsys.co.uk
_______________________________________________
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/dbix-class@lists.scsys.co.uk
_______________________________________________
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/dbix-class@lists.scsys.co.uk
_______________________________________________
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/dbix-class@lists.scsys.co.uk
