Skip Menu |
 

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

Report information
The Basics
Id: 93411
Status: open
Priority: 0/
Queue: DBIx-Class

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

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



Subject: Paged Resultsets unable to return rows due to LIMIT/OFFSET ranges
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
X-RT-Interface: Web
Message-ID: <rt-4.0.18-1928-1393518601-1125.0-0-0 [...] rt.cpan.org>
X-RT-Original-Encoding: utf-8
Content-Type: multipart/mixed; boundary="----------=_1393518601-1928-2"
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 0
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
Content-Length: 639
Download (untitled) / with headers
text/plain 639b
1) Paging a resultset adds offset/limit to the (to be) generated SQL. 2) $self in a resultset refers to the resultset. 3) $self->find($an_id_in_the_resultset); in the resultset triggers the SQL generation SQL on pages 2 and above, will be as follows (page 1 omits the offset causing the bug not to manifest) : SELECT me.id FROM stuff me WHERE ( me.id = ? ) LIMIT ? OFFSET ?: '5', '4', '4' The specific issue is that the SQL server will apply the where clause BEFORE the limit/offset, this causes the SQL to return no results despite the id in question being in the original resultset. Have attached a test case illustrating the issue.
Subject: Test.zip
MIME-Version: 1.0
Content-Type: application/zip; name="Test.zip"
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline; filename="Test.zip"
Content-Transfer-Encoding: base64
Content-Length: 3128
Download Test.zip
application/zip 3k

Message body not shown because it is not plain text.

MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-1928-1393518601-1125.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-1928-1393518601-1125.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-17878-1517159482-1856.93411-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: 594
Download (untitled) / with headers
text/plain 594b
On Thu Feb 27 17:30:01 2014, NYGEL wrote: Show quoted text
> > The specific issue is that the SQL server will apply the where clause > BEFORE the limit/offset, this causes the SQL to return no results > despite the id in question being in the original resultset.
Hi! It has been 4 years since this bug was filed, but on the off-chance it is still relevant: I must say: in general... everything seems to function as designed. Perhaps I am misunderstanding the issue... maybe it manifests on SQL Server only and not on SQLite? If you are still working on the codebase in question - let me know your thoughts!


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.