Bug #129133 for DBIx-Class: DBIx::Class::ResultSetColumn does not respect +select, +as

Thu Apr 11 19:09:57 2019 ether [...] cpan.org - Ticket created

Subject:

DBIx::Class::ResultSetColumn does not respect +select, +as

The comments in DBIx::Class::ResultSetColumn::new suggest that it is intented that +select and +as should also be looked at for column definitions, as well as select/as. However, they are not checked, which results in that part of the query being lost. I think this should get us most of the way there: + my $plus_as_list = $orig_attrs->{'+as'} || []; + my $plus_select_list = $orig_attrs->{'+select'} || []; + my $plus_as_index = List::Util::first { ($plus_as_list->[$_] || "") eq $column } 0..$#$plus_as_list; - my $select = defined $as_index ? $select_list->[$as_index] : $column; + my $select = defined $as_index ? $select_list->[$as_index] : defined $plus_as_index ? $plus_select_list->[$plus_as_index] : $column; (I am using 0.082841 as a reference - the most recent stable release.)

Fri Apr 12 18:44:12 2019 ribasushi [...] leporine.io - Correspondence added

Subject:	Re: [rt.cpan.org #129133] DBIx::Class::ResultSetColumn does not respect +select, +as
Date:	Sat, 13 Apr 2019 00:35:55 +0200
To:	bug-DBIx-Class [...] rt.cpan.org
From:	Peter Rabbitson <ribasushi [...] leporine.io>

On 04/12/2019 01:09 AM, Karen Etheridge via RT wrote: Show quoted text

> > The comments in DBIx::Class::ResultSetColumn::new suggest that it is intented that +select and +as should also be looked at for column definitions, as well as select/as. However, they are not checked, which results in that part of the query being lost. > > I think this should get us most of the way there: > > + my $plus_as_list = $orig_attrs->{'+as'} || []; > + my $plus_select_list = $orig_attrs->{'+select'} || []; > + my $plus_as_index = List::Util::first { ($plus_as_list->[$_] || "") eq $column } 0..$#$plus_as_list; > - my $select = defined $as_index ? $select_list->[$as_index] : $column; > + my $select = defined $as_index ? $select_list->[$as_index] : defined $plus_as_index ? $plus_select_list->[$plus_as_index] : $column; >

Given the patch lacks context markers I couldn't place it precisely. However if I found the correct spot - what you are proposing won't work: $orig_attrs will never contain a '+...' attribute. Please demonstrate with a test what is it you are trying to address, in lieu of what you proposed originally.

Fri Apr 12 18:44:13 2019 The RT System itself - Status changed from 'new' to 'open'

Fri Apr 12 19:48:49 2019 ether [...] cpan.org - Correspondence added

I want to do something like this, on a table with a 'last_used' column which is a timestamp (e.g. postgres 'timestamp with time zone'), to get the timestamp as an epoch time (number with nanosecond precision): my $rs = $old_rs->search( undef, { '+select' => { '' => \('extract(epoch from last_used)'), -as => 'last_used' } }, ); my $last_used = $rs->get_column('last_used'); I can do this if I use 'select', but that removes all existing columns in my resultset; they would need to be re-added afterwards if I ever want to use this resultset without a ->get_column(..). It would be preferable to instead use '+select', so I have the option of using get_column or not. With 'select', the above code generates the query: SELECT ( extract(epoch from mytable.last_used) ) AS last_used FROM mytable mytable; With '+select', the custom query is lost, and it reverts to: SELECT mytable.last_used FROM mytable mytable; In the test suite, this can be seen in t/search/select_chains.t by dumping the result of $rs->get_column('baz')->as_query at about line 113: Leaving 'baz' as a '+select', it is: \[ '(SELECT me.baz FROM cd me)' ] Changing the baz part of the resultset from '+select' to 'select, we get: \[ '(SELECT COUNT( artistid ) AS baz FROM cd me)' ]

Sat Apr 13 03:17:16 2019 ribasushi [...] leporine.io - Correspondence added

Subject:	Re: [rt.cpan.org #129133] DBIx::Class::ResultSetColumn does not respect +select, +as
Date:	Sat, 13 Apr 2019 09:16:57 +0200
To:	bug-DBIx-Class [...] rt.cpan.org
From:	Peter Rabbitson <ribasushi [...] leporine.io>

On 04/13/2019 01:48 AM, Karen Etheridge via RT wrote: Show quoted text

> Queue: DBIx-Class > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=129133 > > > I want to do something like this, on a table with a 'last_used' column > which is a timestamp (e.g. postgres 'timestamp with time zone'), > to get the timestamp as an epoch time (number with nanosecond precision): > > my $rs = $old_rs->search( > undef, > { '+select' => { '' => \('extract(epoch from last_used)'), -as => 'last_used' } }, > ); > my $last_used = $rs->get_column('last_used');

Switch to: { '+columns' => { last_used => { '' => \('extract(epoch from last_used)'), -as => 'last_used' } } } and your problem will go away. You have introduced "dark selection"[1] into your $old_rs, which is why your later-named specification seems to vanish from the callchain. [1] https://metacpan.org/release/DBIx-Class/source/lib/DBIx/Class/ResultSet.pm#L581-582 Please close the ticket if the above answers your question sufficiently.

Mon Apr 15 13:38:37 2019 ether [...] cpan.org - Correspondence added

Yes, thank you, using +columns (i.e. +select and +as) fixes everything... with the exception of now getting "inflate_result() alias 'last_used' specified twice with different SQL-side {select}-ors" (because the same column name is being used), which I am solving with DBIx::Class::Helper::ResultSet::RemoveColumns (which resulted in a mro issue that is not directly related, being discussed on irc).

Mon Apr 15 13:38:38 2019 ether [...] cpan.org - Status changed from 'open' to 'resolved'