This queue is for tickets about the Data-Page CPAN distribution.

Report information
The Basics
Id:
130686
Status:
open
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
Cc:
AdminCc:

BugTracker
Severity:
(no value)
Broken in:
(no value)
Fixed in:
(no value)



Subject: Check for "accessor takes only integers" breaks subclassing
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-10818-1570719575-733.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: 388
The check introduced here: https://github.com/karenetheridge/Data-Page/commit/70286c7fb2f75dd7239c6adb6d1f602964d26299#diff-2b75d6496b291502e446db7dd34f8426R54 Breaks the following subclassing: https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082841/lib/DBIx/Class/ResultSet/Pager.pm If the checks are there to stay, please consider making them standalone methods that can be noop-ed.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-10818-1570719575-733.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-10818-1570719575-733.0-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-30629-1570850106-1508.130686-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: 534
On 2019-10-10 07:59:35, RIBASUSHI wrote:
Show quoted text
> The check introduced here: https://github.com/karenetheridge/Data- > Page/commit/70286c7fb2f75dd7239c6adb6d1f602964d26299#diff- > 2b75d6496b291502e446db7dd34f8426R54 > > Breaks the following subclassing: > https://metacpan.org/source/RIBASUSHI/DBIx-Class- > 0.082841/lib/DBIx/Class/ResultSet/Pager.pm > > If the checks are there to stay, please consider making them > standalone methods that can be noop-ed.
I don't see the problem. Is something calling total_entries with @_ = (undef) ?
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-30629-1570850106-1508.130686-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-10818-1570719575-733.0-0-0@rt.cpan.org> <rt-4.0.18-30629-1570850106-1508.130686-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-31794-1570850455-1699.130686-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: 293
On 2019-10-11 20:15:06, ETHER wrote:
Show quoted text
> I don't see the problem. Is something calling total_entries with @_ = > (undef) ?
Ok I see the situation now. I had to unwind a few levels and find how DBIx::Class::ResultSet was constructing the pager object. I should be able to work something out.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-31794-1570850455-1699.130686-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-10818-1570719575-733.0-0-0@rt.cpan.org> <rt-4.0.18-30629-1570850106-1508.130686-0-0@rt.cpan.org> <rt-4.0.18-31794-1570850455-1699.130686-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-19834-1570890660-739.130686-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: 646
On Sat Oct 12 05:20:55 2019, ETHER wrote:
Show quoted text
> On 2019-10-11 20:15:06, ETHER wrote: >
> > I don't see the problem. Is something calling total_entries with @_ = > > (undef) ?
> > Ok I see the situation now. I had to unwind a few levels and find how > DBIx::Class::ResultSet was constructing the pager object. > > I should be able to work something out.
_05 does fix the priginally reported problem, but this change https://github.com/karenetheridge/Data-Page/commit/49529b87a1 breaks the entire concept of lazily-evaluated-total-count. If this behavior will stay as-is, I need about 2 weeks to fully prepare/test/release a workaround for DBIC.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-19834-1570890660-739.130686-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-10818-1570719575-733.0-0-0@rt.cpan.org> <rt-4.0.18-30629-1570850106-1508.130686-0-0@rt.cpan.org> <rt-4.0.18-31794-1570850455-1699.130686-0-0@rt.cpan.org> <rt-4.0.18-19834-1570890660-739.130686-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-19830-1570896906-1578.130686-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: 528
On 2019-10-12 07:31:00, RIBASUSHI wrote:
Show quoted text
> _05 does fix the priginally reported problem, but this change > https://github.com/karenetheridge/Data-Page/commit/49529b87a1 breaks > the entire concept of lazily-evaluated-total-count. > > If this behavior will stay as-is, I need about 2 weeks to fully > prepare/test/release a workaround for DBIC.
What would you suggest? I would switch to Moo + some XS type checks from Type::Tiny, except that might break something else upstream that depended on the internal accessor methods.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-19830-1570896906-1578.130686-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-10818-1570719575-733.0-0-0@rt.cpan.org> <rt-4.0.18-30629-1570850106-1508.130686-0-0@rt.cpan.org> <rt-4.0.18-31794-1570850455-1699.130686-0-0@rt.cpan.org> <rt-4.0.18-19834-1570890660-739.130686-0-0@rt.cpan.org> <rt-4.0.18-19830-1570896906-1578.130686-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-4374-1570983112-280.130686-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: 684
Current subject: "Reorder of operations breaks existing subclass assumptions"
Show quoted text
> On 2019-10-12 07:31:00, RIBASUSHI wrote: > > ... this change https://github.com/karenetheridge/Data-Page/commit/49529b87a1 breaks the entire concept of lazily-evaluated-total-count
Show quoted text
> On Sat Oct 12 18:15:06 2019, ETHER wrote: > > ... I would switch to Moo + some XS type checks from Type::Tiny...
I do not know how to respond to your suggestion as it focuses on operation implementation. You changed the *ORDER* of operations. My question is twofold: - Are you planning to revert this? - If not - do I have until ~Oct 27th to make a DBIC-side fix for this, or do I need to scramble something ASAP?
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-4374-1570983112-280.130686-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-10818-1570719575-733.0-0-0@rt.cpan.org> <rt-4.0.18-30629-1570850106-1508.130686-0-0@rt.cpan.org> <rt-4.0.18-31794-1570850455-1699.130686-0-0@rt.cpan.org> <rt-4.0.18-19834-1570890660-739.130686-0-0@rt.cpan.org> <rt-4.0.18-19830-1570896906-1578.130686-0-0@rt.cpan.org> <rt-4.0.18-4374-1570983112-280.130686-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-4370-1570984771-1913.130686-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: 893
On 2019-10-13 09:11:52, RIBASUSHI wrote:
Show quoted text
> Current subject: "Reorder of operations breaks existing subclass > assumptions" >
> > On 2019-10-12 07:31:00, RIBASUSHI wrote: > > > > ... this change https://github.com/karenetheridge/Data- > > Page/commit/49529b87a1 breaks the entire concept of lazily-evaluated- > > total-count
>
> > On Sat Oct 12 18:15:06 2019, ETHER wrote: > > > > ... I would switch to Moo + some XS type checks from Type::Tiny...
> > > I do not know how to respond to your suggestion as it focuses on > operation implementation.
I am asking what *you* would prefer to do. Were any of the changes in 2.04 significant (in a positive way) to you?
Show quoted text
> - If not - do I have until ~Oct 27th to make a DBIC-side fix for this, > or do I need to scramble something ASAP?
What is the significance of that date? I had no specific timeline for moving the trial changes to stable.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-4370-1570984771-1913.130686-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-10818-1570719575-733.0-0-0@rt.cpan.org> <rt-4.0.18-30629-1570850106-1508.130686-0-0@rt.cpan.org> <rt-4.0.18-31794-1570850455-1699.130686-0-0@rt.cpan.org> <rt-4.0.18-19834-1570890660-739.130686-0-0@rt.cpan.org> <rt-4.0.18-19830-1570896906-1578.130686-0-0@rt.cpan.org> <rt-4.0.18-4374-1570983112-280.130686-0-0@rt.cpan.org> <rt-4.0.18-4370-1570984771-1913.130686-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-4370-1570986926-665.130686-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: 865
On Sun Oct 13 18:39:31 2019, ETHER wrote:
Show quoted text
> > I am asking what *you* would prefer to do. >
As a consumer I prefer platform-type stuff to not change from under me. On the other hand the use-case of DBIC is *very* unusual, so I do not have a good position to advocate what happens to the future of Data::Page.
Show quoted text
> Were any of the changes in 2.04 significant (in a positive way) to > you?
This is a loaded question, I rather not answer it.
Show quoted text
> What is the significance of that date? I had no specific timeline for > moving the trial changes to stable.
Tentatively I will have time before that date to look into a workaround on my side, so that future changes in Data::Page won't be a concern. I am simply reporting a bug and inquiring what are my options. I rather not go down the path of near-synchronous dialogue - just let me know what are you planning to do.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-4370-1570986926-665.130686-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-10818-1570719575-733.0-0-0@rt.cpan.org> <rt-4.0.18-30629-1570850106-1508.130686-0-0@rt.cpan.org> <rt-4.0.18-31794-1570850455-1699.130686-0-0@rt.cpan.org> <rt-4.0.18-19834-1570890660-739.130686-0-0@rt.cpan.org> <rt-4.0.18-19830-1570896906-1578.130686-0-0@rt.cpan.org> <rt-4.0.18-4374-1570983112-280.130686-0-0@rt.cpan.org> <rt-4.0.18-4370-1570984771-1913.130686-0-0@rt.cpan.org> <rt-4.0.18-4370-1570986926-665.130686-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-23541-1570992040-1531.130686-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: 865
On 2019-10-13 10:15:26, RIBASUSHI wrote:
Show quoted text
> > Were any of the changes in 2.04 significant (in a positive way) to > > you?
> > This is a loaded question, I rather not answer it.
It was not loaded. I was asking if any of those changes are important to you -- that is, if I rolled back everything, would there be more problems.
Show quoted text
> I am simply reporting a bug and inquiring what are my options. I > rather not go down the path of near-synchronous dialogue - just let me > know what are you planning to do.
I will not release changes to the PAUSE index that are known to be breaking an important downstream module. After that, I am trying to find the right course forward, but your terse responses are not helping. At this point I do not understand what the problem is with 49529b87a; I have not been able to reproduce any issues with DBIx::Class::ResultSet::Pager.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-23541-1570992040-1531.130686-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-10818-1570719575-733.0-0-0@rt.cpan.org> <rt-4.0.18-30629-1570850106-1508.130686-0-0@rt.cpan.org> <rt-4.0.18-31794-1570850455-1699.130686-0-0@rt.cpan.org> <rt-4.0.18-19834-1570890660-739.130686-0-0@rt.cpan.org> <rt-4.0.18-19830-1570896906-1578.130686-0-0@rt.cpan.org> <rt-4.0.18-4374-1570983112-280.130686-0-0@rt.cpan.org> <rt-4.0.18-4370-1570984771-1913.130686-0-0@rt.cpan.org> <rt-4.0.18-4370-1570986926-665.130686-0-0@rt.cpan.org> <rt-4.0.18-23541-1570992040-1531.130686-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-24306-1571144091-225.130686-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: 2534
On Sun Oct 13 20:40:40 2019, ETHER wrote:
Show quoted text
> On 2019-10-13 10:15:26, RIBASUSHI wrote: >
> > > Were any of the changes in 2.04 significant (in a positive way) to > > > you?
> > > > This is a loaded question, I rather not answer it.
> > It was not loaded. I was asking if any of those changes are important > to you -- that is, if I rolled back everything, would there be more > problems. >
There would be no problems rom my perspective. Though again - the DBIC use case is very obscure, I rather not have the Data::Page changes be held back by it. I just need a few weeks.
Show quoted text
> > I am simply reporting a bug and inquiring what are my options. I > > rather not go down the path of near-synchronous dialogue - just let > > me > > know what are you planning to do.
> > I will not release changes to the PAUSE index that are known to be > breaking an important downstream module.
Excellent.
Show quoted text
> > After that, I am trying to find the right course forward, but your > terse responses are not helping. At this point I do not understand > what the problem is with 49529b87a; I have not been able to reproduce > any issues with DBIx::Class::ResultSet::Pager.
I made several bad assumptions based on reading https://github.com/karenetheridge/Data-Page/commit/02456a21505a8e7cbc67d34b7911356c2d5a79a6#diff-7d8a9cef418ee48430e98051fff20c8a . Specifically: - The fact that you fixed the bug implied that you understood what the coderef piece is for in the first place - Adding DBIC as an optional test-prereq implied that you ran DBIC's entire test suite against the new version of Data::Page. Now that I know this hasn't happened - here is the gist: - Previously all current_page() checks happened at get-time, which allowed for parts of the stack to be "lazified" - This was (ab)used to skip an expensive `SELECT COUNT(*)...` when the user cares about the first page ( 99% of the cases ) - The change you made forces the sanity check to happen at *object construction time*, which fires the coderef nullifying all lazyfication by virtue of current_page($foo) => last_page() => total_entries() To be even more specific, this block is now impossible to satisfy: https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082841/t/67pager.t#L19-28 With all that said, I again must stress that this is probably the only case of lazification in the wild. Thus having DBIC part ways with Data::Page is likely the correct answer. It isup to you how this ticket gets resolved ( revert or won't-fix ), I should have my side squared away in couple weeks.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-24306-1571144091-225.130686-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-10818-1570719575-733.0-0-0@rt.cpan.org> <rt-4.0.18-30629-1570850106-1508.130686-0-0@rt.cpan.org> <rt-4.0.18-31794-1570850455-1699.130686-0-0@rt.cpan.org> <rt-4.0.18-19834-1570890660-739.130686-0-0@rt.cpan.org> <rt-4.0.18-19830-1570896906-1578.130686-0-0@rt.cpan.org> <rt-4.0.18-4374-1570983112-280.130686-0-0@rt.cpan.org> <rt-4.0.18-4370-1570984771-1913.130686-0-0@rt.cpan.org> <rt-4.0.18-4370-1570986926-665.130686-0-0@rt.cpan.org> <rt-4.0.18-23541-1570992040-1531.130686-0-0@rt.cpan.org> <rt-4.0.18-24306-1571144091-225.130686-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-29839-1571165922-677.130686-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: 2187
On 2019-10-15 05:54:51, RIBASUSHI wrote:
Show quoted text
> I made several bad assumptions based on reading > https://github.com/karenetheridge/Data- > Page/commit/02456a21505a8e7cbc67d34b7911356c2d5a79a6#diff- > 7d8a9cef418ee48430e98051fff20c8a . Specifically: > - The fact that you fixed the bug implied that you understood what the > coderef piece is for in the first place > - Adding DBIC as an optional test-prereq implied that you ran DBIC's > entire test suite against the new version of Data::Page. > > Now that I know this hasn't happened - here is the gist: > - Previously all current_page() checks happened at get-time, which > allowed for parts of the stack to be "lazified" > - This was (ab)used to skip an expensive `SELECT COUNT(*)...` when the > user cares about the first page ( 99% of the cases ) > - The change you made forces the sanity check to happen at *object > construction time*, which fires the coderef nullifying all > lazyfication by virtue of current_page($foo) => last_page() => > total_entries() > > To be even more specific, this block is now impossible to satisfy: > https://metacpan.org/source/RIBASUSHI/DBIx-Class- > 0.082841/t/67pager.t#L19-28
Sorry about that. The test that I added was clearly incomplete and I didn't re-run DBIx::Class's tests after I made the change. I see the issue now.
Show quoted text
> With all that said, I again must stress that this is probably the only > case of lazification in the wild. Thus having DBIC part ways with > Data::Page is likely the correct answer.
Perhaps inlining the calculations into DBIx::Class::ResultSet::Pager might be best (or at least allow for more fine-tuning of hot code paths). That's fine with me as DP's underlying use of accessors is not that great, as you have seen as I have tried to wrestle with improving it :)
Show quoted text
> It isup to you how this ticket gets resolved ( revert or won't-fix ), > I should have my side squared away in couple weeks.
Unless there is an emergency I may not be able to release a fix for this in the next week however. It sounds like you aren't in a position to get a fix out ASAP either, so that's good for both of us. I'm happy to coordinate schedules on irc. Let me know what you need.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-29839-1571165922-677.130686-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-19830-1570896906-1578.130686-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-1169-1573013720-1762.130686-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: 327
On Tue Oct 15 20:58:42 2019, ETHER wrote:
Show quoted text
> > I'm happy to coordinate schedules on irc. Let me know what you need.
Another trial has shipped no longer depending on Data::Page. Seems good so far. Stable should be another ~2 weeks away. Please keep the "eager" version of Data::Page unreleased until I add a "go-ahead" here.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-1169-1573013720-1762.130686-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-19830-1570896906-1578.130686-0-0@rt.cpan.org> <rt-4.0.18-1169-1573013720-1762.130686-0-0@rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-14913-1592339449-628.130686-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: 688
On Wed Nov 06 05:15:20 2019, RIBASUSHI wrote:
Show quoted text
> On Tue Oct 15 20:58:42 2019, ETHER wrote:
> > > > I'm happy to coordinate schedules on irc. Let me know what you need.
> > Another trial has shipped no longer depending on Data::Page. Seems > good so far. Stable should be another ~2 weeks away. > > Please keep the "eager" version of Data::Page unreleased until I add a > "go-ahead" here.
Latest DBIC no longer depends on Data::Page. Do with this dist as you see fit (users who happen to upgrade Data::Page without upgrading their DBIC will see a number of hard-to-explain problems, but such is life on modern CPAN...) Leaving the ticket open as I don't have insights into next steps.
MIME-Version: 1.0
X-Spam-Status: No, score=-5.406 tagged_above=-99.9 required=10 tests=[AWL=0.493, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_OUR_RT=-4, HTML_MESSAGE=0.001] autolearn=ham
In-Reply-To: <rt-4.0.18-14913-1592339449-1694.130686-5-0@rt.cpan.org>
X-Cpan.org: This message routed through the cpan.org mail forwarding service. Please use PAUSE pause.perl.org to configure your delivery settings.
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-130686@rt.cpan.org> <rt-4.0.18-19830-1570896906-1578.130686-5-0@rt.cpan.org> <rt-4.0.18-1169-1573013720-1762.130686-5-0@rt.cpan.org> <rt-4.0.18-14913-1592339449-1694.130686-5-0@rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Received: by 2002:a19:4247:: with SMTP id p68mr2748902lfa.22.1592342728371; Tue, 16 Jun 2020 14:25:28 -0700 (PDT)
Message-ID: <CAPJsHfCg9Ev_DV77qf6sC=rMmBqZOX_-JRGqj1wbDt4j7Hf_5w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="000000000000af86db05a83a2e80"
X-Spam-Score: -5.406
X-Google-SMTP-Source: ABdhPJwywzeoFRiKMExJkVcviUoGxuZQZMAiTcKNUs9U0Dx9ZJ059A1UJ4RKaf7hfKFWjR4kFHlYXil9yLBc0/wFraw=
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i=@froods-org.20150623.gappssmtp.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 0B677240387 for <cpan-bug+Data-Page@hipster.bestpractical.com>; Tue, 16 Jun 2020 17:25:38 -0400 (EDT)
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 ShrycTfb0g5i for <cpan-bug+Data-Page@hipster.bestpractical.com>; Tue, 16 Jun 2020 17:25:34 -0400 (EDT)
Received: from xx1.develooper.com (xx1.develooper.com [147.75.38.233]) by hipster.bestpractical.com (Postfix) with ESMTPS id 2AB15240366 for <bug-Data-Page@rt.cpan.org>; Tue, 16 Jun 2020 17:25:33 -0400 (EDT)
Received: from localhost (xx1.develooper.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 62B1B7C100 for <bug-Data-Page@rt.cpan.org>; Tue, 16 Jun 2020 14:25:33 -0700 (PDT)
Received: from xx1.develooper.com (xx1.develooper.com [127.0.0.1]) by localhost (Postfix) with SMTP id 872DE7CEEC for <bug-Data-Page@rt.cpan.org>; Tue, 16 Jun 2020 14:25:31 -0700 (PDT)
Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by xx1.develooper.com (Postfix) with ESMTPS id E63707C100 for <bug-Data-Page@rt.cpan.org>; Tue, 16 Jun 2020 14:25:29 -0700 (PDT)
Received: by mail-lf1-f41.google.com with SMTP id c11so2282436lfh.8 for <bug-Data-Page@rt.cpan.org>; Tue, 16 Jun 2020 14:25:29 -0700 (PDT)
Delivered-To: cpan-bug+Data-Page@hipster.bestpractical.com
Subject: Re: [rt.cpan.org #130686] Reorder of operations breaks existing subclass assumptions
Return-Path: <karen@froods.org>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=froods-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NOFzX0KrQtVuwO14zyoQWSV0SByuITCsHFytgKaDH9k=; b=BOUqy3/a6tNPUTQXJsuxiekUs4yU+fu6TvusJAXhyRwPzzjOX1F2uCqiGgXMJB6cg3 EWqzCT/mPmXuVDK0MmTpDw4YOJWwZWuSfIiK7eTbGwbC9hpL1lChkgcmDqsKrVcHjXlK wT7tsHVn9/TnyJltJc4yyDDElnhrIpZLU29MpgHzZk0yxq5kYn5XQ/2gKR6LXBVsDHA8 hkYSqezRTTktw/LWPvx0zZaRddmUIjLvegEnrVeJyVg97+FggFSHE2ejmwHwEyYW5bZv K7MYjpJ9CnV8V94Ba4WcSog2SE+Tu8ZuM4cmS+gZVCAHjPLJxoT8suLZij7gLnxtpbPi Sbjw==
X-Original-To: cpan-bug+Data-Page@hipster.bestpractical.com
X-RT-Mail-Extension: data-page
X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NOFzX0KrQtVuwO14zyoQWSV0SByuITCsHFytgKaDH9k=; b=BTrvyOcMSKeyz9Ae/4IrBLmA26+mD2CB/O7VoZzilzoLifOuOlFhz8D4VRs3RUZA9/ g+/iwbp9j1NAwNP27eg36m6sb7PrahHVyyczfypP2kCqSEtWTytCKDBc113ePbykxZoT P/sT2x6wWcJnXWRRIb6L8MbPR5Z0CXWVnRu2QgSSxmuPNX/57pjeganVkouC7JltGjvq DkKovEYRcEZzEwW5D+2+XuPRWXUUyHLbw4q0Bg77IoV69XUZ5QxfhzfX51+93kWiROCY XsKN5FiyAe86qE12xr+9BYRAOFmMK4kOxyLEkkO5AsW4wYVulozz0z2Rh/mIdDKdZRmZ IYgg==
Date: Tue, 16 Jun 2020 14:25:09 -0700
X-PMX-Perl: Suspicious Attachment
X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_NO_HTTP 0.1, SUPERLONG_LINE 0.05, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1900_1999 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, DKIM_SIGNATURE 0, HREF_LABEL_TEXT_NO_URI 0, HREF_LABEL_TEXT_ONLY 0, HTML_BAD_EXTRAS 0, IN_REP_TO 0, KNOWN_MTA_TFX 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, NO_URI_HTTPS 0, REFERENCES 0, SPF_NONE 0, SXL_IP_TFX_WM 0, WEBMAIL_SOURCE 0, __ANY_URI 0, __BODY_TEXT_X4 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FORWARDED_MSG 0, __FUR_RDNS_GMAIL 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __HAS_REFERENCES 0, __HELO_GMAIL 0, __HEX28_LC_BOUNDARY 0, __HREF_LABEL_TEXT 0, __HTML_AHREF_TAG 0, __HTML_BAD_END 0, __HTML_BAD_START 0, __HTML_TAG_DIV 0, __IN_REP_TO 0, __MAIL_CHAIN 0, __MIME_HTML 0, __MIME_TEXT_H 0, __MIME_TEXT_H1 0, __MIME_TEXT_H2 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_TEXT_P2 0, __MIME_VERSION 0, __MSGID_DOMAIN_NOT_IN_HDRS 0, __PHISH_PHRASE1_B 0, __RDNS_WEBMAIL 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_REPLY 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __X_GOOGLE_DKIM_SIGNATURE 0, __YOUTUBE_RCVD 0, __zen.spamhaus.org_ERROR '
X-Spam-Level:
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2019.11.28.70017
To: bug-Data-Page@rt.cpan.org
X-GM-Message-State: AOAM533qo0O8TwaSUQv9EqABAjE6XggdWBocQzE3fK31mVexkq/8Yy9g 5xz2TKi3DqCE6GTuEOYp+zW1ua66KY1bAh2JEByGVOStnek=
From: Karen Etheridge <karen@froods.org>
RT-Message-ID: <rt-4.0.18-16052-1592342739-465.130686-0-0@rt.cpan.org>
Content-Length: 0
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Content-Length: 615
content-type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Content-Length: 1047
On Tue, Jun 16, 2020 at 1:30 PM Peter Rabbitson via RT <bug-Data-Page@rt.cpan.org> wrote:
Show quoted text
Latest DBIC no longer depends on Data::Page. Do with this dist as you see fit (users who happen to upgrade Data::Page without upgrading their DBIC will see a number of hard-to-explain problems, but such is life on modern CPAN...)

Leaving the ticket open as I don't have insights into next steps.

I deleted the trial Data-Page releases from cpan months ago and have no intention of making another release, stable or trial, without thoroughly testing against DBIx::Class (older versions only now, apparently).



This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

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