Skip Menu |
 

This queue is for tickets about the DBIx-Class-ResultSet-RecursiveUpdate CPAN distribution.

Report information
The Basics
Id: 91375
Status: open
Priority: 0/
Queue: DBIx-Class-ResultSet-RecursiveUpdate

People
Owner: Nobody in particular
Requestors: ether [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: possible bug with including constraints in a relationship definition?
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Message-ID: <rt-4.0.18-16245-1386885779-1165.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 836
Download (untitled) / with headers
text/plain 836b
13:45 < ether> I just discovered that when specifying an extra condition in a relationship (the third argument to has_many or whatever), if one wants to add a condition on a field being null, one cannot say "$args->{foreign_alias}.fieldname" => undef -- you have to say "$args->{foreign_alias}.fieldname" => { '=' => undef } 13:46 < ether> with the former, the query isn't even done -- you simply get undef back when you invoke the relationship. 13:46 < ether> I spent a little while trying to figure out why it looked like I had no associated rows :/ 14:08 < jnap> ether: sounds like you found a bug to me, anyone disagree? 14:09 < jnap> I would mostly expect those relationship args to be mostly like search args This seems like too basic an issue to be a real bug, but if so, I'm not sure what I'm doing wrong.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-16245-1386885779-1165.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-16245-1386885779-1165.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-16598-1387410806-1364.91375-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 84
There is now a demonstration test case in topic/rt91375_relationship_null_constraint
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-16598-1387410806-1364.91375-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-16245-1386885779-1165.0-0-0 [...] rt.cpan.org> <rt-4.0.18-16598-1387410806-1364.91375-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-18674-1387442713-671.91375-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 816
Download (untitled) / with headers
text/plain 816b
On Wed Dec 18 18:53:26 2013, ETHER wrote: Show quoted text
> There is now a demonstration test case in > topic/rt91375_relationship_null_constraint
<ribasushi> ether: I played with the test case a bit - I can't seem to get anywhere <ribasushi> ether: your original test in e90ec01b goes 'title' => undef, which never matches because title is non-nullable (so dbic dtrt and does not return you anything) <ribasushi> ether: I expanded and complicated the test in 7c5fc2d, and it still all works as expected <ribasushi> ether: something else is at play, you need to go back to the original situation where you saw the behavior and dig much deeper (that is - I *do* believe you saw something odd, just the current test is *not* it :) Also something I did not mention on IRC - the DBIC_TRACE=1 output looks correct and expected as well.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-18674-1387442713-671.91375-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-16245-1386885779-1165.0-0-0 [...] rt.cpan.org> <rt-4.0.18-16598-1387410806-1364.91375-0-0 [...] rt.cpan.org> <rt-4.0.18-18674-1387442713-671.91375-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-25066-1387476039-138.91375-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1794
Download (untitled) / with headers
text/plain 1.7k
Show quoted text
> <ribasushi> ether: I played with the test case a bit - I can't seem to > get anywhere
Agreed, after fixing up my test to do what I intended originally, it works. I'm including the code below so as to not clutter the git branches further. (For those of the CE inclination who are interested in the source of this issue, I encountered this while writing CE::Schema::SearchMajorGroup->belongs_to(major => ...); with the constraint "$args->{foreign_alias}.delete_time" => { '=', undef }. # in DBICTest::Schema::Artist: __PACKAGE__->has_many( cds_without_genre => 'DBICTest::Schema::CD', sub { my $args = shift; return +{ "$args->{foreign_alias}.artist" => { -ident => "$args->{self_alias}.artistid" }, # this doesn't seem to work... "$args->{foreign_alias}.genreid" => undef, # instead we need to say this: # "$args->{foreign_alias}.genreid" => { '=' => undef }, } }, ); my $rel_rs = $artist_rs->search_related(cds_without_genre => { artist => 1 }, { order_by => ['cdid'] }); # $rel_rs->all_hri should return two rows
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-25066-1387476039-138.91375-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-16245-1386885779-1165.0-0-0 [...] rt.cpan.org> <rt-4.0.18-16598-1387410806-1364.91375-0-0 [...] rt.cpan.org> <rt-4.0.18-18674-1387442713-671.91375-0-0 [...] rt.cpan.org> <rt-4.0.18-25066-1387476039-138.91375-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-30367-1388747046-1931.91375-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 563
Download (untitled) / with headers
text/plain 563b
On Thu Dec 19 13:00:39 2013, ETHER wrote: Show quoted text
> > <ribasushi> ether: I played with the test case a bit - I can't seem > > to > > get anywhere
> > > Agreed, after fixing up my test to do what I intended originally, it > works.
I added your test (with squashing) to master at https://github.com/dbsrgits/dbix-class/commit/18c294f430. Since it is not clear what was causing the issue, and circumstances point to something taking place in your darkpan code, I will close this ticket for the time being. Feel free to reopen when/if more info becomes available. Cheers
From ether [...] cpan.org Fri Jan 3 13: 30:26 2014
X-Sa-Exim-Connect-Ip: 69.50.167.197
MIME-Version: 1.0
X-Spam-Status: No, score=-1.9 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9] autolearn=ham
In-Reply-To: <rt-4.0.18-30367-1388747048-596.91375-6-0 [...] rt.cpan.org>
Content-Disposition: inline
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-91375 [...] rt.cpan.org> <rt-4.0.18-16245-1386885779-1165.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-16598-1387410806-1364.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-18674-1387442713-671.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-25066-1387476039-138.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-30367-1388747048-596.91375-6-0 [...] rt.cpan.org>
X-Acl-Warn: !authenticated = *
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <20140103183008.GT28631 [...] tequila>
content-type: text/plain; charset="utf-8"
X-Spam-Score-Int: 0
X-RT-Original-Encoding: utf-8
X-Spam-Score: -1.9
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 9C9BE240CF6 for <cpan-bug+DBIx-Class [...] hipster.bestpractical.com>; Fri, 3 Jan 2014 13:30:26 -0500 (EST)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i5c+ZbP5Hd1 for <cpan-bug+DBIx-Class [...] hipster.bestpractical.com>; Fri, 3 Jan 2014 13:30:25 -0500 (EST)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 2FC86240AFD for <bug-DBIx-Class [...] rt.cpan.org>; Fri, 3 Jan 2014 13:30:16 -0500 (EST)
Received: (qmail 11554 invoked by alias); 3 Jan 2014 18:30:16 -0000
Received: from ns2.lightspeed.ca (HELO ns2.lightspeed.ca) (206.12.82.4) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Fri, 03 Jan 2014 10:30:14 -0800
Received: from 69-50-167-197.westerncable.ca ([69.50.167.197] helo=etheridge.ca) by ns2.lightspeed.ca with esmtp (Exim 4.72) (envelope-from <ether [...] cpan.org>) id 1Vz9VY-0001uR-IZ for bug-DBIx-Class [...] rt.cpan.org; Fri, 03 Jan 2014 10:30:08 -0800
Delivered-To: cpan-bug+DBIx-Class [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #91375] possible bug with including constraints in a relationship definition?
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Sa-Exim-Mail-From: ether [...] cpan.org
Return-Path: <ether [...] cpan.org>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+DBIx-Class [...] hipster.bestpractical.com
X-RT-Mail-Extension: dbix-class
Date: Fri, 3 Jan 2014 10:30:08 -0800
X-Sa-Exim-Scanned: No (on ns2.lightspeed.ca); SAEximRunCond expanded to false
X-Spam-Level:
X-Spam-Bar: /
To: Peter Rabbitson via RT <bug-DBIx-Class [...] rt.cpan.org>
From: Karen Etheridge <ether [...] cpan.org>
RT-Message-ID: <rt-4.0.18-12213-1388773827-128.91375-0-0 [...] rt.cpan.org>
Content-Length: 585
Download (untitled) / with headers
text/plain 585b
On Fri, Jan 03, 2014 at 06:04:08AM -0500, Peter Rabbitson via RT wrote: Show quoted text
> I added your test (with squashing) to master at https://github.com/dbsrgits/dbix-class/commit/18c294f430. Since it is not clear what was causing the issue, and circumstances point to something taking place in your darkpan code, I will close this ticket for the time being. Feel free to reopen when/if more info becomes available.
It might be related to the column in question (that I was constraining to "must be null") having an inflation to DateTime defined in the schema... will investigate more shortly.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-12213-1388773827-128.91375-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-91375 [...] rt.cpan.org> <rt-4.0.18-16245-1386885779-1165.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-16598-1387410806-1364.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-18674-1387442713-671.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-25066-1387476039-138.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-30367-1388747048-596.91375-6-0 [...] rt.cpan.org> <20140103183008.GT28631 [...] tequila> <rt-4.0.18-12213-1388773827-128.91375-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-599-1409857039-610.91375-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1655
Download (untitled) / with headers
text/plain 1.6k
On Fri Jan 03 19:30:27 2014, ETHER wrote: Show quoted text
> > It might be related to the column in question (that I was constraining > to > "must be null") having an inflation to DateTime defined in the > schema... will > investigate more shortly.
It is and it isn't. While DBIC itself handles the entire situation correctly (and in fact never invokes the inflation/deflation codepath) this is not the case for the DBIx::Class::RecursiveUpdate component (where I am moving this ticket). The problem stems from this line: https://metacpan.org/source/GSHANK/DBIx-Class-ResultSet-RecursiveUpdate-0.34/lib/DBIx/Class/ResultSet/RecursiveUpdate.pm#L202 where DBIC::RU simply takes everything returned from the inocation of the (internal, undocumented, and soon deprecated) _resolve_condition method and tries to assign it via an accessor which of course blows up, given that IC::DT accessors correctly expect a bare DateTime object. There however is a fix, which comes from the massive rewrite of the condition resolver in the upcoming DBIC 0.082800. The new method in question is *still* private, but this is just a precaution in case of a glaring omission being detected in its implementation. Currently the got-to-be-final API looks like this: https://github.com/dbsrgits/dbix-class/blob/8d54fafa1/lib/DBIx/Class/ResultSource.pm#L1835-L1853 What DBIC::RU should do is use the inferred_values hashref in order to do proper assignment. In places where the information *must* be properly resolved - supplying the infer_values_based_on argument will force an all-or-nothing approach. Let me know if this solves your problem and/or if you have any further questions. Cheers
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-599-1409857039-610.91375-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-91375 [...] rt.cpan.org> <rt-4.0.18-16245-1386885779-1165.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-16598-1387410806-1364.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-18674-1387442713-671.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-25066-1387476039-138.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-30367-1388747048-596.91375-6-0 [...] rt.cpan.org> <20140103183008.GT28631 [...] tequila> <rt-4.0.18-12213-1388773827-128.91375-0-0 [...] rt.cpan.org> <rt-4.0.18-599-1409857039-610.91375-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-11769-1443813062-179.91375-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1439
Download (untitled) / with headers
text/plain 1.4k
On 2014-09-04 11:57:19, RIBASUSHI wrote: Show quoted text
> The problem stems from this line: > https://metacpan.org/source/GSHANK/DBIx-Class-ResultSet- > RecursiveUpdate-0.34/lib/DBIx/Class/ResultSet/RecursiveUpdate.pm#L202 > where DBIC::RU simply takes everything returned from the inocation of > the (internal, undocumented, and soon deprecated) _resolve_condition > method and tries to assign it via an accessor which of course blows > up, given that IC::DT accessors correctly expect a bare DateTime > object. > > There however is a fix, which comes from the massive rewrite of the > condition resolver in the upcoming DBIC 0.082800. The new method in > question is *still* private, but this is just a precaution in case of > a glaring omission being detected in its implementation. Currently the > got-to-be-final API looks like this: https://github.com/dbsrgits/dbix- > class/blob/8d54fafa1/lib/DBIx/Class/ResultSource.pm#L1835-L1853 > > What DBIC::RU should do is use the inferred_values hashref in order to > do proper assignment. In places where the information *must* be > properly resolved - supplying the infer_values_based_on argument will > force an all-or-nothing approach. Let me know if this solves your > problem and/or if you have any further questions.
What can we do about this ticket? I have code (and features) that are blocked on not being able to construct proper join conditions in relationships that are used by some forms.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-11769-1443813062-179.91375-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-91375 [...] rt.cpan.org> <rt-4.0.18-16245-1386885779-1165.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-16598-1387410806-1364.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-18674-1387442713-671.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-25066-1387476039-138.91375-6-0 [...] rt.cpan.org> <rt-4.0.18-30367-1388747048-596.91375-6-0 [...] rt.cpan.org> <20140103183008.GT28631 [...] tequila> <rt-4.0.18-12213-1388773827-128.91375-0-0 [...] rt.cpan.org> <rt-4.0.18-599-1409857039-610.91375-0-0 [...] rt.cpan.org> <rt-4.0.18-11769-1443813062-179.91375-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-5199-1443826982-912.91375-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 212
Download (untitled) / with headers
text/plain 212b
Show quoted text
> What can we do about this ticket? I have code (and features) that are > blocked on not being able to construct proper join conditions in > relationships that are used by some forms.
Do you have a testcase?


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.