<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><blockquote type="cite" class="clean_bq"><div dir="ltr"><font face="arial, helvetica, sans-serif"><b>>"<span class="pln" style="white-space: pre;">GET</span> <span class="pun" style="color: rgb(102, 102, 0); white-space: pre;">/</span><span class="pln" style="white-space: pre;">app</span><span class="pun" style="color: rgb(102, 102, 0); white-space: pre;">/</span><span class="pln" style="white-space: pre;">items</span><span class="pun" style="color: rgb(102, 102, 0); white-space: pre;">?</span><span class="pln" style="white-space: pre;">f_updated_at</span>=gte:some_timestamp"</b></font></div></blockquote></div> <div><br></div><div>I guess this should only return existing entries in a collection, while the proposition was to add deleted entries to the result too (if we use changes_since). More like a delta, than simple filtering.</div><div><br></div> <div id="bloop_sign_1439208890529933824" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Kirill Zaitsev<br>Murano team</div><div style="font-family:helvetica,arial;font-size:13px">Software Engineer</div><div style="font-family:helvetica,arial;font-size:13px">Mirantis, Inc</div></div> <br><p class="airmail_on" style="color:#000;">On 10 Aug 2015 at 07:10:23, hao wang (<a href="mailto:sxmatch1986@gmail.com">sxmatch1986@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<div dir="ltr">
<div>Hi, stackers</div>
<div><br></div>
Since now we have merged filtering guideline[1], is that said
we should implement this feature according this guideline?
like this:
<div><br></div>
<div><font face="arial, helvetica, sans-serif"><b>"<span class="pln" style="color:rgb(0,0,0);white-space:pre">GET</span>
<span class="pun" style="color:rgb(102,102,0);white-space:pre">/</span><span class="pln" style="color:rgb(0,0,0);white-space:pre">app</span><span class="pun" style="color:rgb(102,102,0);white-space:pre">/</span><span class="pln" style="color:rgb(0,0,0);white-space:pre">items</span><span class="pun" style="color:rgb(102,102,0);white-space:pre">?</span><span class="pln" style="color:rgb(0,0,0);white-space:pre">f_updated_at</span>=gte:some_timestamp"</b></font></div>
<div><font face="arial, helvetica, sans-serif"><b><br></b></font></div>
<div><font face="arial, helvetica, sans-serif">Do we have reached
a consensus about this?</font></div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-06-19 17:07 GMT+08:00 Chris Dent
<span dir="ltr"><<a href="mailto:chdent@redhat.com" target="_blank">chdent@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There's an open question in the API-WG on whether to formalize
or<br>
otherwise enshrine the concept of a "changes-since" query
parameter<br>
on collection oriented resources across the projects. The
original<br>
source of this concept is from Nova's API:<br>
<br>
<a href="http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html</a><br>
<br>
There are arguments for and against but we've been unable to reach
a<br>
consensus so the agreed next step was to bring the issue to
the<br>
mailing list so more people can hash it out and provide their
input.<br>
The hope is that concerns or constraints that those in the
group<br>
are not aware of will be revealed and a better decision will
be<br>
reached.<br>
<br>
The basic idea of "changes-since" is that it can be used as a way
to<br>
signal that the requestor is doing some polling and would like
to<br>
ask "Give me stuff that has changed since the last time I
checked".<br>
As I understand it, for the current implementations (in Nova
and<br>
Glance) this means "including stuff that has been deleted".
Repeated<br>
requests to the resource with a "changes-since" parameter gives
a<br>
running report on the evolving state of the resource. This is
intended<br>
to allow "efficient polling"[0].<br>
<br>
The pro camp on this likes it because this is very useful and
quite<br>
humane: The requestor doesn't need to know the details of how
the<br>
query is is implemented under the hood. That is, if there are<br>
several timestamps associated with the singular resources in
the<br>
collection which of those are used for time comparison and
which<br>
attributes (such as "state" with a value of "deleted") are used
to<br>
determine if a singular resource is included. The service gets
to<br>
decide these things and in order for "efficient polling" to
actually<br>
be achieved it needs to do in order to make effective queries of
the<br>
data store.<br>
<br>
The con camp doesn't like it because it introduces magic,
ambiguity<br>
and inconsistency into the API (when viewed from a
cross-project<br>
perspective) and one of the defining goals of the working group
is<br>
to slowly guide things to some measure of consistency. The<br>
alternate approach is to formulate a fairly rigorous query
system<br>
for both filtering[1] and sorting[2] and use that to specify<br>
explicit queries that state "I want resources that are newer than
time<br>
X in timestamp attribute 'updated_at' _and_ have attribute
'state'<br>
that is one of 'foo', 'bar' or 'baz'".<br>
<br>
(I hope I have represented the two camps properly here and
not<br>
introduced any bias. Myself I'm completely on the fence. If
you<br>
think I've misrepresented the state of things please post a<br>
clarifying response.)<br>
<br>
The questions come down to:<br>
<br>
* Are there additional relevant pros and cons for the two
proposals?<br>
* Are there additional proposals which can address the
shortcomings<br>
in either?<br>
<br>
Thanks for your input.<br>
<br>
[0] Please try to refrain from responses on the line of "ha!<br>
efficiency! that's hilarious!" and "ZOMG, polling,
that's so<br>
last century". Everybody knows this already and it's
not<br>
germane to the immediate concerns. We'll get to a
fully message<br>
driven architecture next week. This week we're still
working<br>
with what we've got.<br>
[1] filtering guideline proposal<br>
<a href="https://review.openstack.org/#/c/177468/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/177468/</a><br>
[2] sorting guideline proposal<br>
<a href="https://review.openstack.org/#/c/145579/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/145579/</a><span class="HOEnZb"><font color="#888888"><br>
--<br>
Chris Dent tw:@anticdent freenode:cdent<br>
<a href="https://tank.peermore.com/tanks/cdent" rel="noreferrer" target="_blank">https://tank.peermore.com/tanks/cdent</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote>
</div>
<br>
<br clear="all">
<div><br></div>
--<br>
<div class="gmail_signature">
<pre>Best Wishes For You!
</pre></div>
</div>
</div>
</div>
__________________________________________________________________________
<br>OpenStack Development Mailing List (not for usage questions)
<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<br></div></div></span></blockquote></body></html>