Re: [PATCH RFC] events-api: allow filtering by date

[Stephen Finucane]

On Wed, 2017-06-14 at 14:14 -0400, Aaron Conole wrote:
> This commit allows users of the REST API to query for events based on
> the date field.  This will allow utility writers to select a smaller
> subset of events when polling.
> 
> Signed-off-by: Aaron Conole 

Reviewed-by: Stephen Finucane 

...and applied. Thanks, Aaron.

Stephen

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH RFC] events-api: allow filtering by date

[aconole]

Ugh. I cannot figure out how to properly respond with this stupid phone. 
Apologies for the wretched format. 
 Original message From: Stephen Finucane <step...@that.guru> 
Date: 6/21/17  4:47 PM  (GMT-05:00) To: Aaron Conole <acon...@bytheb.org> Cc: 
patchwork@lists.ozlabs.org Subject: Re: [PATCH RFC] events-api: allow filtering 
by date 
On Wed, 2017-06-21 at 21:08 +0100, Stephen Finucane wrote:
> On Thu, 2017-06-15 at 09:57 -0400, Aaron Conole wrote:
> > Stephen Finucane <step...@that.guru> writes:
> > 
> > > On Wed, 2017-06-14 at 14:16 -0400, Aaron Conole wrote:
> > > > Aaron Conole <acon...@bytheb.org> writes:
> > > > 
> > > > > This commit allows users of the REST API to query for events based on
> > > > > the date field.  This will allow utility writers to select a smaller
> > > > > subset of events when polling.
> > > > > 
> > > > > Signed-off-by: Aaron Conole <acon...@bytheb.org>
> > > 
> > > I think I missed this initially because I'd intended to use cursor-based
> > > pagination [1] for '/events'. Cursor-based pagination would be beneficial
> > > in so
> > > far as it allows us to grab a pseudo-permalink to page of events, which
> > > isn't
> > > possible with page number-based pagination because the page numbers can
> > > change
> > > way to darn quick. However, it does make '/events' unique in how it does
> > > pagination. I can go either way with this, and can submit an RFC for this
> > > this
> > > evening, if it would help to compare the two.
> > 
> > Sure; I'm fairly inexperienced with web development, so I don't
> > understand the nuance between the two approaches.
> 
> Sorry for the delay. I've just submitted that RFC now.
> 
> To compare the two, I'd suggest you take a look at the below:
> 
>   https://www.sitepoint.com/paginating-real-time-data-cursor-based-pagination
> /
> 
> The gist is that the high volume of events makes it likely that stuff will
> get
> lost between pages. This really makes sense for '/events' and it might even
> make sense for '/patches' and '/series' (as they're also sorted in
> chronological order by default), though I doubt we'll change those now.

...then again, we could accomplish the same thing with the 'until' filter. So
long as someone specifies this, we shouldn't see anything getting entered in
between the pages.

I think we can ignore my RFC and merge this, if you agree?


Stephen


-
Sounds good to me. Sorry for the late reply. I am on vacation and have limited 
email access. ___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH RFC] events-api: allow filtering by date

[Stephen Finucane]

On Thu, 2017-06-15 at 09:57 -0400, Aaron Conole wrote:
> Stephen Finucane  writes:
> 
> > On Wed, 2017-06-14 at 14:16 -0400, Aaron Conole wrote:
> > > Aaron Conole  writes:
> > > 
> > > > This commit allows users of the REST API to query for events based on
> > > > the date field.  This will allow utility writers to select a smaller
> > > > subset of events when polling.
> > > > 
> > > > Signed-off-by: Aaron Conole 
> > 
> > I think I missed this initially because I'd intended to use cursor-based
> > pagination [1] for '/events'. Cursor-based pagination would be beneficial
> > in so
> > far as it allows us to grab a pseudo-permalink to page of events, which
> > isn't
> > possible with page number-based pagination because the page numbers can
> > change
> > way to darn quick. However, it does make '/events' unique in how it does
> > pagination. I can go either way with this, and can submit an RFC for this
> > this
> > evening, if it would help to compare the two.
> 
> Sure; I'm fairly inexperienced with web development, so I don't
> understand the nuance between the two approaches.

Sorry for the delay. I've just submitted that RFC now.

To compare the two, I'd suggest you take a look at the below:

  https://www.sitepoint.com/paginating-real-time-data-cursor-based-pagination/

The gist is that the high volume of events makes it likely that stuff will get
lost between pages. This really makes sense for '/events' and it might even
make sense for '/patches' and '/series' (as they're also sorted in
chronological order by default), though I doubt we'll change those now.

> > > > ---
> > > 
> > > It should be noted that my motivation for this is to implement a git-pw
> > > event poll command for CI integration.
> > 
> > Hmm, so I'll admit I'm not overly fond of this idea. I'm trying to keep
> > git-pw
> > as a client side tool for git-patchwork interaction and not a catch-all
> > application for all things Patchwork like pwclient currently is. "Create a
> > check" doesn't sound like something Acme developer would be doing from
> > within
> > their Git repo.
> 
> Okay.  I'm approaching this from the angle of "I want to do X, how do I
> achieve it today." :)  I thought it made sense to have a running stream
> of events that I could poll on, especially since I envision the workflow
> like:
> 
> 1. Wake up
> 2. Do human things
> 3. git pw events list --category=series-new* --since=
> 4. scroll through that work (ie: git pw series apply X, review, comment,
>    etc. keep going until all are done)
> 5. go to 3.

Actually, that makes sense. I'd be game to accept a PR for this. What I
wouldn't be a fan of is integrating checks and I thought this is what you were
suggesting.

> Maybe I'm not thinking about events correctly, though?
> 
> Then I could basically make steps 3,4,5 be done by a machine instead,
> and have it run things like checkpatch, make check, etc.  I'll look at
> the snowpatch tool, as well.  Thanks.

Yeah, anything that can be automated should be. Machines, however, shouldn't be
using git-pw - they should make their own calls or use some kind of as-yet-non-
existent Patchwork REST library.

Cheers,
Stephen
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH RFC] events-api: allow filtering by date

[Aaron Conole]

Andrew Donnellan  writes:

> On 15/06/17 09:59, Daniel Axtens wrote:
>> Aaron Conole  writes:
>>
>>> Aaron Conole  writes:
>>>
 This commit allows users of the REST API to query for events based on
 the date field.  This will allow utility writers to select a smaller
 subset of events when polling.

 Signed-off-by: Aaron Conole 
 ---
>>>
>>> It should be noted that my motivation for this is to implement a git-pw
>>> event poll command for CI integration.
>>>
>>> If you think there's a better way of achieving this, let me know.
>>
>> You should check out Snowpatch: Andrew Donnellan and Russell Currey (on
>> this list) are the developers.
>>
>> https://developer.ibm.com/open/openprojects/snowpatch/
>>
>> I don't know how they do it but I'm sure they'd be happy to explain it
>> at length :)
>
> We don't currently use the events API at all - we just poll the
> patches API at fixed intervals and look for patches that don't already
> have test results. We might change this approach in future.

Thanks for the pointers.  I'll check this out.
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH RFC] events-api: allow filtering by date

[Andrew Donnellan]

On 15/06/17 09:59, Daniel Axtens wrote:

Aaron Conole  writes:


Aaron Conole  writes:


This commit allows users of the REST API to query for events based on
the date field.  This will allow utility writers to select a smaller
subset of events when polling.

Signed-off-by: Aaron Conole 
---


It should be noted that my motivation for this is to implement a git-pw
event poll command for CI integration.

If you think there's a better way of achieving this, let me know.


You should check out Snowpatch: Andrew Donnellan and Russell Currey (on
this list) are the developers.

https://developer.ibm.com/open/openprojects/snowpatch/

I don't know how they do it but I'm sure they'd be happy to explain it
at length :)


We don't currently use the events API at all - we just poll the patches 
API at fixed intervals and look for patches that don't already have test 
results. We might change this approach in future.


--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH RFC] events-api: allow filtering by date

[Daniel Axtens]

Aaron Conole  writes:

> Aaron Conole  writes:
>
>> This commit allows users of the REST API to query for events based on
>> the date field.  This will allow utility writers to select a smaller
>> subset of events when polling.
>>
>> Signed-off-by: Aaron Conole 
>> ---
>
> It should be noted that my motivation for this is to implement a git-pw
> event poll command for CI integration.
>
> If you think there's a better way of achieving this, let me know.

You should check out Snowpatch: Andrew Donnellan and Russell Currey (on
this list) are the developers.

https://developer.ibm.com/open/openprojects/snowpatch/

I don't know how they do it but I'm sure they'd be happy to explain it
at length :)

Regards,
Daniel
>
> -Aaron
> ___
> Patchwork mailing list
> Patchwork@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [PATCH RFC] events-api: allow filtering by date

[Aaron Conole]

Aaron Conole  writes:

> This commit allows users of the REST API to query for events based on
> the date field.  This will allow utility writers to select a smaller
> subset of events when polling.
>
> Signed-off-by: Aaron Conole 
> ---

It should be noted that my motivation for this is to implement a git-pw
event poll command for CI integration.

If you think there's a better way of achieving this, let me know.

-Aaron
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

[PATCH RFC] events-api: allow filtering by date

[Aaron Conole]

This commit allows users of the REST API to query for events based on
the date field.  This will allow utility writers to select a smaller
subset of events when polling.

Signed-off-by: Aaron Conole 
---
 patchwork/api/filters.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/patchwork/api/filters.py b/patchwork/api/filters.py
index 3dc215c..666a3d8 100644
--- a/patchwork/api/filters.py
+++ b/patchwork/api/filters.py
@@ -127,7 +127,7 @@ class CheckFilter(TimestampMixin, FilterSet):
 fields = ('user', 'state', 'context')
 
 
-class EventFilter(ProjectMixin, FilterSet):
+class EventFilter(ProjectMixin, TimestampMixin, FilterSet):
 
 class Meta:
 model = Event
-- 
2.9.4
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork