updated release has broken my code

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

updated release has broken my code

Dave Howorth
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.

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@...
Reply | Threaded
Open this post in threaded view
|

Re: updated release has broken my code

Lasse Makholm


On Wed, Jan 20, 2016 at 4:32 PM, Dave Howorth <[hidden email]> 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.


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
 

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


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: updated release has broken my code

Dave Howorth


On 2016-01-20 18:21, Lasse Makholm wrote:

> On Wed, Jan 20, 2016 at 4:32 PM, Dave Howorth <[hidden email]>
> 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@...
>>
>
>
> _______________________________________________
> 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@...


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: updated release has broken my code

Dave Howorth
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
>> <[hidden email]>
>> 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@...
>>>
>>
>>
>> _______________________________________________
>> 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@...
>
>
> _______________________________________________
> 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@...
>


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: updated release has broken my code

Dave Howorth
In reply to this post by Dave Howorth


On 2016-01-21 17:07, Peter Rabbitson wrote:

> On 01/20/2016 04:32 PM, Dave Howorth 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.
>
> This is related to RT#107462. I am still deep into the txn rework so I
> have not yet looked into this properly. I apologize for the great
> delay, there have been too many distractions lately :(
>
> Please add a note to the RT in question, linking to this exchange, so
> I do not end up dropping it on the floor in the coming week.
>
> In the meantime the best I can recommend is freeze the version for a
> bit longer.
I've added a comment to the bug pointing back to this thread. Thanks for
all your hard work on DBIx::Class.

Cheers, Dave

_______________________________________________
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@...