You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Raymond Auge <ra...@liferay.com> on 2008/04/04 02:05:51 UTC
Returing the total entities count
Hello All,
There does not appear to be a way to return the total number of some
entity through any of the APIs.
I only see a way of returning a list of entities. Not the total count
(which I'd need in order to build some pagination).
Perhaps I missed something?
Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.
Re: Returing the total entities count
Posted by Cassie <do...@google.com>.
Yeah, that makes a lot of sense Paul.
On Thu, Apr 10, 2008 at 2:26 AM, Paul Lindner <pl...@hi5.com> wrote:
>
> Passing in the computed ids and the idSpec would allow the implementer
> to do what they wanted. This also solves the problem of the
> TOP_FRIENDS sort -- currently there's no way to determine this since
> we don't know if it's the top friends for the owner/viewer given
> OWNER_FRIENDS or VIEWER_FRIENDS.
>
>
>
>
>
> On 4/6/08 8:29 AM, "Cassie" <do...@apache.org> wrote:
>
> > The js api supports paging, sorting and filtering. See this page:
> > http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataReque
> > st.PeopleRequestFields.html
> >
> > The java api supports pagination for the PeopleService for this function:
> >
> > public ResponseItem<ApiCollection<Person>> getPeople(List<String> ids,
> > SortOrder sortOrder, FilterType filter, int first, int max,
> > Set<String> profileDetails, GadgetToken token);
> >
> > It just doesn't support pagination for the getIds function. We could
> > add pagination to the getIds function but then that function would
> > need to know how to sort. But if it needs to know how to sort then it
> > has to have activity, profile and data info. That doesn't seem like a
> > really good pattern though.
> >
> > One possible way to do things would be to get rid of the getIds
> > function and to have each getPeople, getActivities, getData call
> > translate the idSpec into a list of ids itself. That eliminates some
> > of the nice separation that we currently have though.
> >
> > So, I'm not sure how we want to handle this. Feel free to propose a solution.
> > Thanks.
> >
> > - Cassie
> >
> >
> > On Sat, Apr 5, 2008 at 5:41 AM, Raymond Auge <ra...@doublebite.com> wrote:
> >>
> >> There should be some way if providing an integer total from the backend to
> >> the front end... returning a list of 10,000,000 ids is simply not
> >> acceptable...
> >>
> >> Now, I'm fairly certain that no one will ever have 10,000,000 friends... (I
> >> certainly don't :) ). BUT... it's more an issue of scalability... It is
> >> certainly conceivable that I have thousands of events... and it'd be nice to
> >> be able to get that number without ever having to get them all...
> >>
> >> These services need methods to return the total for a given userId.
> >>
> >> org.apache.shindig.social.opensocial.ActivitiesService
> >> org.apache.shindig.social.opensocial.PeopleService
> >>
> >> This method needs paging support...
> >>
> >> List<String>
> >> org.apache.shindig.social.opensocial.PeopleService.getIds(IdSpec idSpec,
> >> GadgetToken token) throws JSONException
> >>
> >> This method needs paging support:
> >>
> >> ResponseItem<List<Activity>>
> >> org.apache.shindig.social.opensocial.ActivitiesService.getActivities(List<Str
> >> ing>
> >> userIds, GadgetToken token)
> >>
> >> I think this missing functionality extends all the way to the front end JS
> >> API.
> >>
> >> AGAIN... maybe I'm just not understanding it all correctly. If so, can
> >> someone explain it to me?
> >>
> >> Ray
> >>
> >>
> >>
> >> On Fri, 2008-04-04 at 23:22 -0400, Raymond Auge wrote:
> >> Suppose for example I have 10,000,000 Friends... I certainly don't want
> >> to ever present them all in the UI... secondly, thought I can specify
> >> that I want one page from "first" to "first + max", but that does not
> >> provide me with any way to tell the UI that there are 10,000,000, so
> >> that I can display the total and/or produce a page list...
> >>
> >> So, like I said, I might just be missing something and/or not
> >> understanding the usage of the API (at least from the backend
> >> perspective)???
> >>
> >> It's simply wrong to have to produce the total based on returning the
> >> total result set and then pruning out the desired page.
> >>
> >> i.e. How can I get the total number of "friends" WITHOUT returning them
> >> all from the DB? This doesn't seem possible through any of the methods
> >> in the backend service tier.
> >>
> >>
> >> Ray
> >>
> >> On Fri, 2008-04-04 at 10:13 +0200, Cassie wrote:
> >>
> >>> Which entities are you talking about?
> >>>
> >>> - Cassie
> >>>
> >>>
> >>> On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <ra...@liferay.com> wrote:
> >>>> Hello All,
> >>>>
> >>>> There does not appear to be a way to return the total number of some
> >>>> entity through any of the APIs.
> >>>>
> >>>> I only see a way of returning a list of entities. Not the total count
> >>>> (which I'd need in order to build some pagination).
> >>>>
> >>>> Perhaps I missed something?
> >>>>
> >>>> Raymond Augé
> >>>> Software Engineer
> >>>> Liferay, Inc.
> >>>> Enterprise. Open Source. For Life.
> >>>>
> >>>
> >>
> >> Raymond Augé
> >> Software Engineer
> >> Liferay, Inc.
> >> Enterprise. Open Source. For Life.
> >>
> >>
> >> Raymond Augé
> >> Software Engineer
> >> Liferay, Inc.
> >> Enterprise. Open Source. For Life.
>
>
Re: Returing the total entities count
Posted by Alejandro Rivero <al...@gmail.com>.
2008/4/10 Cassie <do...@google.com>:
> Oh, nm, I completely misread that.
> I dunno though... it seems like that code could be pretty confusing -
> if it just gets fixed in 0.8 that we won't have code ugliness :)
legacy always cause ugliness :-(
Lets wait for 0.8 then. My kids will survive with this setup anyway.
Re: Returing the total entities count
Posted by Cassie <do...@google.com>.
Oh, nm, I completely misread that.
I dunno though... it seems like that code could be pretty confusing -
if it just gets fixed in 0.8 that we won't have code ugliness :)
- Cassie
On Thu, Apr 10, 2008 at 12:59 PM, Cassie <do...@google.com> wrote:
> Alejandro - this is exactly what the js is doing - the syntax is just
> condensed a little bit:
> return {'activities' : new opensocial.Collection(activities)};
>
> - Cassie
>
>
>
>
> On Wed, Apr 9, 2008 at 9:20 PM, Alejandro Rivero <al...@gmail.com> wrote:
> > I am astonished (only a bit; "legacy code" was to be expected in the
> > jump from 0.5). And I am sorry I missed that line in the
> > specification; so it is true, the javascript is doing the right thing.
> >
> > I have raised issues 140 and 141 in
> > http://code.google.com/p/opensocial-resources/issues/list
> > as suggested.
> >
> > The report of the bug in JIRA could be closed, but instead I'd suggest the patch
> >
> > var activityCollection = new opensocial.Collection(activities);
> > activityCollection.activities = activityCollection;
> > return activityCollection;
> >
> > or whatever the javascript code is, to add a new property to an
> > object. In this way, we keep with the specification and we return too
> > a full featured Collection<activitity>.
> >
> > Alejandro
> >
> > 2008/4/9 Cassie <do...@google.com>:
> >
> >
> > > Ah, I see. Actually, if you look carefully, Shindig is doing the right
> > > thing in javascript. The spec specifically says "When processed,
> > > returns an object whose "activities" property is a
> > > Collection<Activity> object." so is you do getData.activities, that
> > > should be a collection.
> > >
> > > This is a relic from the 0.5 apis where there was also a "stream"
> > > property. So.. the spec is sorta weird, and should be fixed. But
> > > Shindig is doing the right thing in javascript.
> > >
> > > - Cassie
> > >
> > >
> > >
> > >
> > > On Wed, Apr 9, 2008 at 4:44 PM, Alejandro Rivero <al...@gmail.com> wrote:
> > > > just to clarify; the problem is not that there is not paging, the real
> > > > problem is that neither .getData().each() nor .getData().size work
> > > > when the answer is a collection of activities, while they do work when
> > > > the request is for a collection of persons.
> > > >
> > > > 2008/4/9 Alejandro Rivero <al...@gmail.com>:
> > > >
> > > >
> > > > > 2008/4/9 Cassie <do...@apache.org>:
> > > > >
> > > > >
> > > > > > So the Shindig java code is doing the right thing.
> > > > > > If we think activities should have paging, then someone should just
> > > > > > bring it up on the spec mailing list.
> > > > > >
> > > > > > - Cassie
> > > > > >
> > > > >
> > > > > Yep, it is doing the right thing. The bug is in the javascript side, I
> > > > > just sent a report.
> > > > >
> > > >
> > >
> >
>
Re: Returing the total entities count
Posted by Cassie <do...@google.com>.
Alejandro - this is exactly what the js is doing - the syntax is just
condensed a little bit:
return {'activities' : new opensocial.Collection(activities)};
- Cassie
On Wed, Apr 9, 2008 at 9:20 PM, Alejandro Rivero <al...@gmail.com> wrote:
> I am astonished (only a bit; "legacy code" was to be expected in the
> jump from 0.5). And I am sorry I missed that line in the
> specification; so it is true, the javascript is doing the right thing.
>
> I have raised issues 140 and 141 in
> http://code.google.com/p/opensocial-resources/issues/list
> as suggested.
>
> The report of the bug in JIRA could be closed, but instead I'd suggest the patch
>
> var activityCollection = new opensocial.Collection(activities);
> activityCollection.activities = activityCollection;
> return activityCollection;
>
> or whatever the javascript code is, to add a new property to an
> object. In this way, we keep with the specification and we return too
> a full featured Collection<activitity>.
>
> Alejandro
>
> 2008/4/9 Cassie <do...@google.com>:
>
>
> > Ah, I see. Actually, if you look carefully, Shindig is doing the right
> > thing in javascript. The spec specifically says "When processed,
> > returns an object whose "activities" property is a
> > Collection<Activity> object." so is you do getData.activities, that
> > should be a collection.
> >
> > This is a relic from the 0.5 apis where there was also a "stream"
> > property. So.. the spec is sorta weird, and should be fixed. But
> > Shindig is doing the right thing in javascript.
> >
> > - Cassie
> >
> >
> >
> >
> > On Wed, Apr 9, 2008 at 4:44 PM, Alejandro Rivero <al...@gmail.com> wrote:
> > > just to clarify; the problem is not that there is not paging, the real
> > > problem is that neither .getData().each() nor .getData().size work
> > > when the answer is a collection of activities, while they do work when
> > > the request is for a collection of persons.
> > >
> > > 2008/4/9 Alejandro Rivero <al...@gmail.com>:
> > >
> > >
> > > > 2008/4/9 Cassie <do...@apache.org>:
> > > >
> > > >
> > > > > So the Shindig java code is doing the right thing.
> > > > > If we think activities should have paging, then someone should just
> > > > > bring it up on the spec mailing list.
> > > > >
> > > > > - Cassie
> > > > >
> > > >
> > > > Yep, it is doing the right thing. The bug is in the javascript side, I
> > > > just sent a report.
> > > >
> > >
> >
>
Re: Returing the total entities count
Posted by Alejandro Rivero <al...@gmail.com>.
I am astonished (only a bit; "legacy code" was to be expected in the
jump from 0.5). And I am sorry I missed that line in the
specification; so it is true, the javascript is doing the right thing.
I have raised issues 140 and 141 in
http://code.google.com/p/opensocial-resources/issues/list
as suggested.
The report of the bug in JIRA could be closed, but instead I'd suggest the patch
var activityCollection = new opensocial.Collection(activities);
activityCollection.activities = activityCollection;
return activityCollection;
or whatever the javascript code is, to add a new property to an
object. In this way, we keep with the specification and we return too
a full featured Collection<activitity>.
Alejandro
2008/4/9 Cassie <do...@google.com>:
> Ah, I see. Actually, if you look carefully, Shindig is doing the right
> thing in javascript. The spec specifically says "When processed,
> returns an object whose "activities" property is a
> Collection<Activity> object." so is you do getData.activities, that
> should be a collection.
>
> This is a relic from the 0.5 apis where there was also a "stream"
> property. So.. the spec is sorta weird, and should be fixed. But
> Shindig is doing the right thing in javascript.
>
> - Cassie
>
>
>
>
> On Wed, Apr 9, 2008 at 4:44 PM, Alejandro Rivero <al...@gmail.com> wrote:
> > just to clarify; the problem is not that there is not paging, the real
> > problem is that neither .getData().each() nor .getData().size work
> > when the answer is a collection of activities, while they do work when
> > the request is for a collection of persons.
> >
> > 2008/4/9 Alejandro Rivero <al...@gmail.com>:
> >
> >
> > > 2008/4/9 Cassie <do...@apache.org>:
> > >
> > >
> > > > So the Shindig java code is doing the right thing.
> > > > If we think activities should have paging, then someone should just
> > > > bring it up on the spec mailing list.
> > > >
> > > > - Cassie
> > > >
> > >
> > > Yep, it is doing the right thing. The bug is in the javascript side, I
> > > just sent a report.
> > >
> >
>
Re: Returing the total entities count
Posted by Cassie <do...@google.com>.
Ah, I see. Actually, if you look carefully, Shindig is doing the right
thing in javascript. The spec specifically says "When processed,
returns an object whose "activities" property is a
Collection<Activity> object." so is you do getData.activities, that
should be a collection.
This is a relic from the 0.5 apis where there was also a "stream"
property. So.. the spec is sorta weird, and should be fixed. But
Shindig is doing the right thing in javascript.
- Cassie
On Wed, Apr 9, 2008 at 4:44 PM, Alejandro Rivero <al...@gmail.com> wrote:
> just to clarify; the problem is not that there is not paging, the real
> problem is that neither .getData().each() nor .getData().size work
> when the answer is a collection of activities, while they do work when
> the request is for a collection of persons.
>
> 2008/4/9 Alejandro Rivero <al...@gmail.com>:
>
>
> > 2008/4/9 Cassie <do...@apache.org>:
> >
> >
> > > So the Shindig java code is doing the right thing.
> > > If we think activities should have paging, then someone should just
> > > bring it up on the spec mailing list.
> > >
> > > - Cassie
> > >
> >
> > Yep, it is doing the right thing. The bug is in the javascript side, I
> > just sent a report.
> >
>
Re: Returing the total entities count
Posted by Alejandro Rivero <al...@gmail.com>.
just to clarify; the problem is not that there is not paging, the real
problem is that neither .getData().each() nor .getData().size work
when the answer is a collection of activities, while they do work when
the request is for a collection of persons.
2008/4/9 Alejandro Rivero <al...@gmail.com>:
> 2008/4/9 Cassie <do...@apache.org>:
>
>
> > So the Shindig java code is doing the right thing.
> > If we think activities should have paging, then someone should just
> > bring it up on the spec mailing list.
> >
> > - Cassie
> >
>
> Yep, it is doing the right thing. The bug is in the javascript side, I
> just sent a report.
>
Re: Returing the total entities count
Posted by Alejandro Rivero <al...@gmail.com>.
2008/4/9 Cassie <do...@apache.org>:
> So the Shindig java code is doing the right thing.
> If we think activities should have paging, then someone should just
> bring it up on the spec mailing list.
>
> - Cassie
>
Yep, it is doing the right thing. The bug is in the javascript side, I
just sent a report.
Re: Returing the total entities count
Posted by Cassie <do...@apache.org>.
As the javascript spec says here:
http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.html#newFetchActivitiesRequest
The fetch activities call should return a Collection of Activity
objects. However, the api does not allow paging, so you are correct,
the size will always be equal to the totalSize.
So the Shindig java code is doing the right thing.
If we think activities should have paging, then someone should just
bring it up on the spec mailing list.
- Cassie
On Wed, Apr 9, 2008 at 2:53 PM, Alejandro Rivero <al...@gmail.com> wrote:
> Hmm now we are on the activities side and I noticed the way to
> getTotalSize is somehow obscure. Raymond, the working way to extract
> the info out from the returned data is to use
> .getData().activities.size()
> .getData().activities.getTotalSize(); //of course, the same that
> above, because there is not paging.
> .getData().activities.each(...)
>
> And so on.
>
> Now, I am not very sure about if other containers in real life (hi,
> hi5!) do it in this way. Note that the API says that
> midataresponse.get(id) is a ResponseItem
> miresponseitem.getData() is an Object, "the requested value calculated
> by the server; the type of this value is defined by the type of
> request that was made"
>
> The problem is how to build this Object back to a Collection, and then
> the undocumented answer in shindig javascript is that you get the
> Collection as a property:
> miresponseitem.getData().activities is a ApiCollection of Activities
>
> Now, are we sure this is the standard? Or is it a bug?
>
>
>
>
> 2008/4/6 Alejandro Rivero <al...@gmail.com>:
>
>
> > Probably he wants to know the value of MAX in order to present the
> > user a complete pagination bar, not just a "more>>" tag.
> > The blame is on "ResponseItem", whose documentation does not specify
> > any way to know how many objects has it found, and one must to go to
> > the Api entry for Collection in order to discover the use of
> > .getTotalSize() versus .size()
> >
> > Actually, the hint comes from looking at BasicPeopleService
> >
> > int totalSize = people.size();
> > int last = first + max;
> > people = people.subList(first, Math.min(last, totalSize));
> > ApiCollection<Person> collection = new ApiCollection<Person>(people,
> > first, totalSize);
> >
> > whose Collection returns totalSize, as Raymon asks.
> >
> >
> >
> >
> >
> > BTW, the Filter HasApp seems very useful for interaction between
> > users. I hope real containers will implement it!
> >
> > 2008/4/6 Cassie <do...@apache.org>:
> >
> >
> > > The js api supports paging, sorting and filtering. See this page:
> > > http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.PeopleRequestFields.html
> > >
> > > The java api supports pagination for the PeopleService for this function:
> > >
> > > public ResponseItem<ApiCollection<Person>> getPeople(List<String> ids,
> > > SortOrder sortOrder, FilterType filter, int first, int max,
> > > Set<String> profileDetails, GadgetToken token);
> > >
> > > It just doesn't support pagination for the getIds function. We could
> > > add pagination to the getIds function but then that function would
> > > need to know how to sort. But if it needs to know how to sort then it
> > > has to have activity, profile and data info. That doesn't seem like a
> > > really good pattern though.
> > >
> > > One possible way to do things would be to get rid of the getIds
> > > function and to have each getPeople, getActivities, getData call
> > > translate the idSpec into a list of ids itself. That eliminates some
> > > of the nice separation that we currently have though.
> > >
> > > So, I'm not sure how we want to handle this. Feel free to propose a solution.
> > > Thanks.
> > >
> > > - Cassie
> > >
> > >
> > > On Sat, Apr 5, 2008 at 5:41 AM, Raymond Auge <ra...@doublebite.com> wrote:
> > > >
> > > > There should be some way if providing an integer total from the backend to
> > > > the front end... returning a list of 10,000,000 ids is simply not
> > > > acceptable...
> > > >
> > > > Now, I'm fairly certain that no one will ever have 10,000,000 friends... (I
> > > > certainly don't :) ). BUT... it's more an issue of scalability... It is
> > > > certainly conceivable that I have thousands of events... and it'd be nice to
> > > > be able to get that number without ever having to get them all...
> > > >
> > > > These services need methods to return the total for a given userId.
> > > >
> > > > org.apache.shindig.social.opensocial.ActivitiesService
> > > > org.apache.shindig.social.opensocial.PeopleService
> > > >
> > > > This method needs paging support...
> > > >
> > > > List<String>
> > > > org.apache.shindig.social.opensocial.PeopleService.getIds(IdSpec idSpec,
> > > > GadgetToken token) throws JSONException
> > > >
> > > > This method needs paging support:
> > > >
> > > > ResponseItem<List<Activity>>
> > > > org.apache.shindig.social.opensocial.ActivitiesService.getActivities(List<String>
> > > > userIds, GadgetToken token)
> > > >
> > > > I think this missing functionality extends all the way to the front end JS
> > > > API.
> > > >
> > > > AGAIN... maybe I'm just not understanding it all correctly. If so, can
> > > > someone explain it to me?
> > > >
> > > > Ray
> > >
> > >
> > > >
> > > >
> > > >
> > > > On Fri, 2008-04-04 at 23:22 -0400, Raymond Auge wrote:
> > > > Suppose for example I have 10,000,000 Friends... I certainly don't want
> > > > to ever present them all in the UI... secondly, thought I can specify
> > > > that I want one page from "first" to "first + max", but that does not
> > > > provide me with any way to tell the UI that there are 10,000,000, so
> > > > that I can display the total and/or produce a page list...
> > > >
> > > > So, like I said, I might just be missing something and/or not
> > > > understanding the usage of the API (at least from the backend
> > > > perspective)???
> > > >
> > > > It's simply wrong to have to produce the total based on returning the
> > > > total result set and then pruning out the desired page.
> > > >
> > > > i.e. How can I get the total number of "friends" WITHOUT returning them
> > > > all from the DB? This doesn't seem possible through any of the methods
> > > > in the backend service tier.
> > > >
> > > >
> > > > Ray
> > > >
> > > > On Fri, 2008-04-04 at 10:13 +0200, Cassie wrote:
> > > >
> > > > > Which entities are you talking about?
> > > > >
> > > > > - Cassie
> > > > >
> > > > >
> > > > > On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <ra...@liferay.com> wrote:
> > > > > > Hello All,
> > > > > >
> > > > > > There does not appear to be a way to return the total number of some
> > > > > > entity through any of the APIs.
> > > > > >
> > > > > > I only see a way of returning a list of entities. Not the total count
> > > > > > (which I'd need in order to build some pagination).
> > > > > >
> > > > > > Perhaps I missed something?
> > > > > >
> > > > > > Raymond Augé
> > > > > > Software Engineer
> > > > > > Liferay, Inc.
> > > > > > Enterprise. Open Source. For Life.
> > > > > >
> > > > >
> > > >
> > > > Raymond Augé
> > > > Software Engineer
> > > > Liferay, Inc.
> > > > Enterprise. Open Source. For Life.
> > > >
> > > >
> > > > Raymond Augé
> > > > Software Engineer
> > > > Liferay, Inc.
> > > > Enterprise. Open Source. For Life.
> > >
> >
>
Re: Returing the total entities count
Posted by Alejandro Rivero <al...@gmail.com>.
Hmm now we are on the activities side and I noticed the way to
getTotalSize is somehow obscure. Raymond, the working way to extract
the info out from the returned data is to use
.getData().activities.size()
.getData().activities.getTotalSize(); //of course, the same that
above, because there is not paging.
.getData().activities.each(...)
And so on.
Now, I am not very sure about if other containers in real life (hi,
hi5!) do it in this way. Note that the API says that
midataresponse.get(id) is a ResponseItem
miresponseitem.getData() is an Object, "the requested value calculated
by the server; the type of this value is defined by the type of
request that was made"
The problem is how to build this Object back to a Collection, and then
the undocumented answer in shindig javascript is that you get the
Collection as a property:
miresponseitem.getData().activities is a ApiCollection of Activities
Now, are we sure this is the standard? Or is it a bug?
2008/4/6 Alejandro Rivero <al...@gmail.com>:
> Probably he wants to know the value of MAX in order to present the
> user a complete pagination bar, not just a "more>>" tag.
> The blame is on "ResponseItem", whose documentation does not specify
> any way to know how many objects has it found, and one must to go to
> the Api entry for Collection in order to discover the use of
> .getTotalSize() versus .size()
>
> Actually, the hint comes from looking at BasicPeopleService
>
> int totalSize = people.size();
> int last = first + max;
> people = people.subList(first, Math.min(last, totalSize));
> ApiCollection<Person> collection = new ApiCollection<Person>(people,
> first, totalSize);
>
> whose Collection returns totalSize, as Raymon asks.
>
>
>
>
>
> BTW, the Filter HasApp seems very useful for interaction between
> users. I hope real containers will implement it!
>
> 2008/4/6 Cassie <do...@apache.org>:
>
>
> > The js api supports paging, sorting and filtering. See this page:
> > http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.PeopleRequestFields.html
> >
> > The java api supports pagination for the PeopleService for this function:
> >
> > public ResponseItem<ApiCollection<Person>> getPeople(List<String> ids,
> > SortOrder sortOrder, FilterType filter, int first, int max,
> > Set<String> profileDetails, GadgetToken token);
> >
> > It just doesn't support pagination for the getIds function. We could
> > add pagination to the getIds function but then that function would
> > need to know how to sort. But if it needs to know how to sort then it
> > has to have activity, profile and data info. That doesn't seem like a
> > really good pattern though.
> >
> > One possible way to do things would be to get rid of the getIds
> > function and to have each getPeople, getActivities, getData call
> > translate the idSpec into a list of ids itself. That eliminates some
> > of the nice separation that we currently have though.
> >
> > So, I'm not sure how we want to handle this. Feel free to propose a solution.
> > Thanks.
> >
> > - Cassie
> >
> >
> > On Sat, Apr 5, 2008 at 5:41 AM, Raymond Auge <ra...@doublebite.com> wrote:
> > >
> > > There should be some way if providing an integer total from the backend to
> > > the front end... returning a list of 10,000,000 ids is simply not
> > > acceptable...
> > >
> > > Now, I'm fairly certain that no one will ever have 10,000,000 friends... (I
> > > certainly don't :) ). BUT... it's more an issue of scalability... It is
> > > certainly conceivable that I have thousands of events... and it'd be nice to
> > > be able to get that number without ever having to get them all...
> > >
> > > These services need methods to return the total for a given userId.
> > >
> > > org.apache.shindig.social.opensocial.ActivitiesService
> > > org.apache.shindig.social.opensocial.PeopleService
> > >
> > > This method needs paging support...
> > >
> > > List<String>
> > > org.apache.shindig.social.opensocial.PeopleService.getIds(IdSpec idSpec,
> > > GadgetToken token) throws JSONException
> > >
> > > This method needs paging support:
> > >
> > > ResponseItem<List<Activity>>
> > > org.apache.shindig.social.opensocial.ActivitiesService.getActivities(List<String>
> > > userIds, GadgetToken token)
> > >
> > > I think this missing functionality extends all the way to the front end JS
> > > API.
> > >
> > > AGAIN... maybe I'm just not understanding it all correctly. If so, can
> > > someone explain it to me?
> > >
> > > Ray
> >
> >
> > >
> > >
> > >
> > > On Fri, 2008-04-04 at 23:22 -0400, Raymond Auge wrote:
> > > Suppose for example I have 10,000,000 Friends... I certainly don't want
> > > to ever present them all in the UI... secondly, thought I can specify
> > > that I want one page from "first" to "first + max", but that does not
> > > provide me with any way to tell the UI that there are 10,000,000, so
> > > that I can display the total and/or produce a page list...
> > >
> > > So, like I said, I might just be missing something and/or not
> > > understanding the usage of the API (at least from the backend
> > > perspective)???
> > >
> > > It's simply wrong to have to produce the total based on returning the
> > > total result set and then pruning out the desired page.
> > >
> > > i.e. How can I get the total number of "friends" WITHOUT returning them
> > > all from the DB? This doesn't seem possible through any of the methods
> > > in the backend service tier.
> > >
> > >
> > > Ray
> > >
> > > On Fri, 2008-04-04 at 10:13 +0200, Cassie wrote:
> > >
> > > > Which entities are you talking about?
> > > >
> > > > - Cassie
> > > >
> > > >
> > > > On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <ra...@liferay.com> wrote:
> > > > > Hello All,
> > > > >
> > > > > There does not appear to be a way to return the total number of some
> > > > > entity through any of the APIs.
> > > > >
> > > > > I only see a way of returning a list of entities. Not the total count
> > > > > (which I'd need in order to build some pagination).
> > > > >
> > > > > Perhaps I missed something?
> > > > >
> > > > > Raymond Augé
> > > > > Software Engineer
> > > > > Liferay, Inc.
> > > > > Enterprise. Open Source. For Life.
> > > > >
> > > >
> > >
> > > Raymond Augé
> > > Software Engineer
> > > Liferay, Inc.
> > > Enterprise. Open Source. For Life.
> > >
> > >
> > > Raymond Augé
> > > Software Engineer
> > > Liferay, Inc.
> > > Enterprise. Open Source. For Life.
> >
>
Re: Returing the total entities count
Posted by Alejandro Rivero <al...@gmail.com>.
Probably he wants to know the value of MAX in order to present the
user a complete pagination bar, not just a "more>>" tag.
The blame is on "ResponseItem", whose documentation does not specify
any way to know how many objects has it found, and one must to go to
the Api entry for Collection in order to discover the use of
.getTotalSize() versus .size()
Actually, the hint comes from looking at BasicPeopleService
int totalSize = people.size();
int last = first + max;
people = people.subList(first, Math.min(last, totalSize));
ApiCollection<Person> collection = new ApiCollection<Person>(people,
first, totalSize);
whose Collection returns totalSize, as Raymon asks.
BTW, the Filter HasApp seems very useful for interaction between
users. I hope real containers will implement it!
2008/4/6 Cassie <do...@apache.org>:
> The js api supports paging, sorting and filtering. See this page:
> http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.PeopleRequestFields.html
>
> The java api supports pagination for the PeopleService for this function:
>
> public ResponseItem<ApiCollection<Person>> getPeople(List<String> ids,
> SortOrder sortOrder, FilterType filter, int first, int max,
> Set<String> profileDetails, GadgetToken token);
>
> It just doesn't support pagination for the getIds function. We could
> add pagination to the getIds function but then that function would
> need to know how to sort. But if it needs to know how to sort then it
> has to have activity, profile and data info. That doesn't seem like a
> really good pattern though.
>
> One possible way to do things would be to get rid of the getIds
> function and to have each getPeople, getActivities, getData call
> translate the idSpec into a list of ids itself. That eliminates some
> of the nice separation that we currently have though.
>
> So, I'm not sure how we want to handle this. Feel free to propose a solution.
> Thanks.
>
> - Cassie
>
>
> On Sat, Apr 5, 2008 at 5:41 AM, Raymond Auge <ra...@doublebite.com> wrote:
> >
> > There should be some way if providing an integer total from the backend to
> > the front end... returning a list of 10,000,000 ids is simply not
> > acceptable...
> >
> > Now, I'm fairly certain that no one will ever have 10,000,000 friends... (I
> > certainly don't :) ). BUT... it's more an issue of scalability... It is
> > certainly conceivable that I have thousands of events... and it'd be nice to
> > be able to get that number without ever having to get them all...
> >
> > These services need methods to return the total for a given userId.
> >
> > org.apache.shindig.social.opensocial.ActivitiesService
> > org.apache.shindig.social.opensocial.PeopleService
> >
> > This method needs paging support...
> >
> > List<String>
> > org.apache.shindig.social.opensocial.PeopleService.getIds(IdSpec idSpec,
> > GadgetToken token) throws JSONException
> >
> > This method needs paging support:
> >
> > ResponseItem<List<Activity>>
> > org.apache.shindig.social.opensocial.ActivitiesService.getActivities(List<String>
> > userIds, GadgetToken token)
> >
> > I think this missing functionality extends all the way to the front end JS
> > API.
> >
> > AGAIN... maybe I'm just not understanding it all correctly. If so, can
> > someone explain it to me?
> >
> > Ray
>
>
> >
> >
> >
> > On Fri, 2008-04-04 at 23:22 -0400, Raymond Auge wrote:
> > Suppose for example I have 10,000,000 Friends... I certainly don't want
> > to ever present them all in the UI... secondly, thought I can specify
> > that I want one page from "first" to "first + max", but that does not
> > provide me with any way to tell the UI that there are 10,000,000, so
> > that I can display the total and/or produce a page list...
> >
> > So, like I said, I might just be missing something and/or not
> > understanding the usage of the API (at least from the backend
> > perspective)???
> >
> > It's simply wrong to have to produce the total based on returning the
> > total result set and then pruning out the desired page.
> >
> > i.e. How can I get the total number of "friends" WITHOUT returning them
> > all from the DB? This doesn't seem possible through any of the methods
> > in the backend service tier.
> >
> >
> > Ray
> >
> > On Fri, 2008-04-04 at 10:13 +0200, Cassie wrote:
> >
> > > Which entities are you talking about?
> > >
> > > - Cassie
> > >
> > >
> > > On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <ra...@liferay.com> wrote:
> > > > Hello All,
> > > >
> > > > There does not appear to be a way to return the total number of some
> > > > entity through any of the APIs.
> > > >
> > > > I only see a way of returning a list of entities. Not the total count
> > > > (which I'd need in order to build some pagination).
> > > >
> > > > Perhaps I missed something?
> > > >
> > > > Raymond Augé
> > > > Software Engineer
> > > > Liferay, Inc.
> > > > Enterprise. Open Source. For Life.
> > > >
> > >
> >
> > Raymond Augé
> > Software Engineer
> > Liferay, Inc.
> > Enterprise. Open Source. For Life.
> >
> >
> > Raymond Augé
> > Software Engineer
> > Liferay, Inc.
> > Enterprise. Open Source. For Life.
>
Re: Returing the total entities count
Posted by Ian Boston <ie...@tfd.co.uk>.
This isnt really my thread, but, as someone who might have to provide
the implementation.
I would support putting the separation below the API, ie getPeople,
getActivities, getData
since if its above the API
A) the implementation of the API is restricted in how it expresses
and selects ID's (eg has to return the whole set, which in the case
of people may be large, activities would probably have some natural
server defined limit (eg last 30 days or 30 items, whichever is less)
B) it reduces the chattiness over the API, improving possibilities to
remote the call in necessary.
C) it frees the implementation from exposing its internal ID's or
translating to another form.
there is nothing really compelling in any of these arguments for
getPeople, getActivities, getData but it just feels like a simpler
API and may prevent a double get on the data under the API.
A concrete example.
I store my recent activity in a lucene index (its fast :) )+indexing
backlog queue, with a date field and I can perform a search on that
index with a custom query string, from which I retrieve the ID's, but
for the list of ID's i need to emit 1 query (or a compound query for
a set) per ID..... when I had a good pointer to the record in the
first call.
I store the Data in Jackrabbit, so when I get the ID's under getData
I do a jcr getNode(), this pulls into memory all the contents of the
node, just to extract some concept of an ID. Later on in the next
call I need to convert the getNode() ID into the real data, hence I
call getNode() again.... fortunately Jackrabbit has excellent
caching, so there is no problem, it just comes from memory.
I think I am saying, in practice, the cost of the getIDs type call
may be as expensive (if not more without filtering and sorting) as
the final get data call... so why not do the get data call in the
first place ?
As I said, not my thread, sorry for butting in.
Ian
On 6 Apr 2008, at 16:29, Cassie wrote:
> The js api supports paging, sorting and filtering. See this page:
> http://code.google.com/apis/opensocial/docs/0.7/reference/
> opensocial.DataRequest.PeopleRequestFields.html
>
> The java api supports pagination for the PeopleService for this
> function:
>
> public ResponseItem<ApiCollection<Person>> getPeople(List<String> ids,
> SortOrder sortOrder, FilterType filter, int first, int max,
> Set<String> profileDetails, GadgetToken token);
>
> It just doesn't support pagination for the getIds function. We could
> add pagination to the getIds function but then that function would
> need to know how to sort. But if it needs to know how to sort then it
> has to have activity, profile and data info. That doesn't seem like a
> really good pattern though.
>
> One possible way to do things would be to get rid of the getIds
> function and to have each getPeople, getActivities, getData call
> translate the idSpec into a list of ids itself. That eliminates some
> of the nice separation that we currently have though.
>
> So, I'm not sure how we want to handle this. Feel free to propose a
> solution.
> Thanks.
>
> - Cassie
>
>
> On Sat, Apr 5, 2008 at 5:41 AM, Raymond Auge
> <ra...@doublebite.com> wrote:
>>
>> There should be some way if providing an integer total from the
>> backend to
>> the front end... returning a list of 10,000,000 ids is simply not
>> acceptable...
>>
>> Now, I'm fairly certain that no one will ever have 10,000,000
>> friends... (I
>> certainly don't :) ). BUT... it's more an issue of scalability...
>> It is
>> certainly conceivable that I have thousands of events... and it'd
>> be nice to
>> be able to get that number without ever having to get them all...
>>
>> These services need methods to return the total for a given userId.
>>
>> org.apache.shindig.social.opensocial.ActivitiesService
>> org.apache.shindig.social.opensocial.PeopleService
>>
>> This method needs paging support...
>>
>> List<String>
>> org.apache.shindig.social.opensocial.PeopleService.getIds(IdSpec
>> idSpec,
>> GadgetToken token) throws JSONException
>>
>> This method needs paging support:
>>
>> ResponseItem<List<Activity>>
>> org.apache.shindig.social.opensocial.ActivitiesService.getActivities(
>> List<String>
>> userIds, GadgetToken token)
>>
>> I think this missing functionality extends all the way to the
>> front end JS
>> API.
>>
>> AGAIN... maybe I'm just not understanding it all correctly. If
>> so, can
>> someone explain it to me?
>>
>> Ray
>>
>>
>>
>> On Fri, 2008-04-04 at 23:22 -0400, Raymond Auge wrote:
>> Suppose for example I have 10,000,000 Friends... I certainly
>> don't want
>> to ever present them all in the UI... secondly, thought I can specify
>> that I want one page from "first" to "first + max", but that does not
>> provide me with any way to tell the UI that there are 10,000,000, so
>> that I can display the total and/or produce a page list...
>>
>> So, like I said, I might just be missing something and/or not
>> understanding the usage of the API (at least from the backend
>> perspective)???
>>
>> It's simply wrong to have to produce the total based on returning the
>> total result set and then pruning out the desired page.
>>
>> i.e. How can I get the total number of "friends" WITHOUT returning
>> them
>> all from the DB? This doesn't seem possible through any of the
>> methods
>> in the backend service tier.
>>
>>
>> Ray
>>
>> On Fri, 2008-04-04 at 10:13 +0200, Cassie wrote:
>>
>>> Which entities are you talking about?
>>>
>>> - Cassie
>>>
>>>
>>> On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <ra...@liferay.com>
>>> wrote:
>>>> Hello All,
>>>>
>>>> There does not appear to be a way to return the total number of
>>>> some
>>>> entity through any of the APIs.
>>>>
>>>> I only see a way of returning a list of entities. Not the total
>>>> count
>>>> (which I'd need in order to build some pagination).
>>>>
>>>> Perhaps I missed something?
>>>>
>>>> Raymond Augé
>>>> Software Engineer
>>>> Liferay, Inc.
>>>> Enterprise. Open Source. For Life.
>>>>
>>>
>>
>> Raymond Augé
>> Software Engineer
>> Liferay, Inc.
>> Enterprise. Open Source. For Life.
>>
>>
>> Raymond Augé
>> Software Engineer
>> Liferay, Inc.
>> Enterprise. Open Source. For Life.
Re: Returing the total entities count
Posted by Cassie <do...@apache.org>.
Oh, and getActivities doesn't support paging. The container just
returns the last set of relevant activities sorted in an appropriate
order. Activities are not guaranteed to be stored for all of time like
people are - especially because there is an infinite set of them.
The container is free to return as little or as many activities as it wants.
If you think this is incorrect then you can email a spec change
proposal to the <op...@googlegroups.com>
Thanks.
- Cassie
On Sun, Apr 6, 2008 at 5:29 PM, Cassie <do...@apache.org> wrote:
> The js api supports paging, sorting and filtering. See this page:
> http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.PeopleRequestFields.html
>
> The java api supports pagination for the PeopleService for this function:
>
> public ResponseItem<ApiCollection<Person>> getPeople(List<String> ids,
> SortOrder sortOrder, FilterType filter, int first, int max,
> Set<String> profileDetails, GadgetToken token);
>
> It just doesn't support pagination for the getIds function. We could
> add pagination to the getIds function but then that function would
> need to know how to sort. But if it needs to know how to sort then it
> has to have activity, profile and data info. That doesn't seem like a
> really good pattern though.
>
> One possible way to do things would be to get rid of the getIds
> function and to have each getPeople, getActivities, getData call
> translate the idSpec into a list of ids itself. That eliminates some
> of the nice separation that we currently have though.
>
> So, I'm not sure how we want to handle this. Feel free to propose a solution.
> Thanks.
>
> - Cassie
>
>
>
>
> On Sat, Apr 5, 2008 at 5:41 AM, Raymond Auge <ra...@doublebite.com> wrote:
> >
> > There should be some way if providing an integer total from the backend to
> > the front end... returning a list of 10,000,000 ids is simply not
> > acceptable...
> >
> > Now, I'm fairly certain that no one will ever have 10,000,000 friends... (I
> > certainly don't :) ). BUT... it's more an issue of scalability... It is
> > certainly conceivable that I have thousands of events... and it'd be nice to
> > be able to get that number without ever having to get them all...
> >
> > These services need methods to return the total for a given userId.
> >
> > org.apache.shindig.social.opensocial.ActivitiesService
> > org.apache.shindig.social.opensocial.PeopleService
> >
> > This method needs paging support...
> >
> > List<String>
> > org.apache.shindig.social.opensocial.PeopleService.getIds(IdSpec idSpec,
> > GadgetToken token) throws JSONException
> >
> > This method needs paging support:
> >
> > ResponseItem<List<Activity>>
> > org.apache.shindig.social.opensocial.ActivitiesService.getActivities(List<String>
> > userIds, GadgetToken token)
> >
> > I think this missing functionality extends all the way to the front end JS
> > API.
> >
> > AGAIN... maybe I'm just not understanding it all correctly. If so, can
> > someone explain it to me?
> >
> > Ray
> >
> >
> >
> > On Fri, 2008-04-04 at 23:22 -0400, Raymond Auge wrote:
> > Suppose for example I have 10,000,000 Friends... I certainly don't want
> > to ever present them all in the UI... secondly, thought I can specify
> > that I want one page from "first" to "first + max", but that does not
> > provide me with any way to tell the UI that there are 10,000,000, so
> > that I can display the total and/or produce a page list...
> >
> > So, like I said, I might just be missing something and/or not
> > understanding the usage of the API (at least from the backend
> > perspective)???
> >
> > It's simply wrong to have to produce the total based on returning the
> > total result set and then pruning out the desired page.
> >
> > i.e. How can I get the total number of "friends" WITHOUT returning them
> > all from the DB? This doesn't seem possible through any of the methods
> > in the backend service tier.
> >
> >
> > Ray
> >
> > On Fri, 2008-04-04 at 10:13 +0200, Cassie wrote:
> >
> > > Which entities are you talking about?
> > >
> > > - Cassie
> > >
> > >
> > > On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <ra...@liferay.com> wrote:
> > > > Hello All,
> > > >
> > > > There does not appear to be a way to return the total number of some
> > > > entity through any of the APIs.
> > > >
> > > > I only see a way of returning a list of entities. Not the total count
> > > > (which I'd need in order to build some pagination).
> > > >
> > > > Perhaps I missed something?
> > > >
> > > > Raymond Augé
> > > > Software Engineer
> > > > Liferay, Inc.
> > > > Enterprise. Open Source. For Life.
> > > >
> > >
> >
> > Raymond Augé
> > Software Engineer
> > Liferay, Inc.
> > Enterprise. Open Source. For Life.
> >
> >
> > Raymond Augé
> > Software Engineer
> > Liferay, Inc.
> > Enterprise. Open Source. For Life.
>
Re: Returing the total entities count
Posted by Paul Lindner <pl...@hi5.com>.
Passing in the computed ids and the idSpec would allow the implementer
to do what they wanted. This also solves the problem of the
TOP_FRIENDS sort -- currently there's no way to determine this since
we don't know if it's the top friends for the owner/viewer given
OWNER_FRIENDS or VIEWER_FRIENDS.
On 4/6/08 8:29 AM, "Cassie" <do...@apache.org> wrote:
> The js api supports paging, sorting and filtering. See this page:
> http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataReque
> st.PeopleRequestFields.html
>
> The java api supports pagination for the PeopleService for this function:
>
> public ResponseItem<ApiCollection<Person>> getPeople(List<String> ids,
> SortOrder sortOrder, FilterType filter, int first, int max,
> Set<String> profileDetails, GadgetToken token);
>
> It just doesn't support pagination for the getIds function. We could
> add pagination to the getIds function but then that function would
> need to know how to sort. But if it needs to know how to sort then it
> has to have activity, profile and data info. That doesn't seem like a
> really good pattern though.
>
> One possible way to do things would be to get rid of the getIds
> function and to have each getPeople, getActivities, getData call
> translate the idSpec into a list of ids itself. That eliminates some
> of the nice separation that we currently have though.
>
> So, I'm not sure how we want to handle this. Feel free to propose a solution.
> Thanks.
>
> - Cassie
>
>
> On Sat, Apr 5, 2008 at 5:41 AM, Raymond Auge <ra...@doublebite.com> wrote:
>>
>> There should be some way if providing an integer total from the backend to
>> the front end... returning a list of 10,000,000 ids is simply not
>> acceptable...
>>
>> Now, I'm fairly certain that no one will ever have 10,000,000 friends... (I
>> certainly don't :) ). BUT... it's more an issue of scalability... It is
>> certainly conceivable that I have thousands of events... and it'd be nice to
>> be able to get that number without ever having to get them all...
>>
>> These services need methods to return the total for a given userId.
>>
>> org.apache.shindig.social.opensocial.ActivitiesService
>> org.apache.shindig.social.opensocial.PeopleService
>>
>> This method needs paging support...
>>
>> List<String>
>> org.apache.shindig.social.opensocial.PeopleService.getIds(IdSpec idSpec,
>> GadgetToken token) throws JSONException
>>
>> This method needs paging support:
>>
>> ResponseItem<List<Activity>>
>> org.apache.shindig.social.opensocial.ActivitiesService.getActivities(List<Str
>> ing>
>> userIds, GadgetToken token)
>>
>> I think this missing functionality extends all the way to the front end JS
>> API.
>>
>> AGAIN... maybe I'm just not understanding it all correctly. If so, can
>> someone explain it to me?
>>
>> Ray
>>
>>
>>
>> On Fri, 2008-04-04 at 23:22 -0400, Raymond Auge wrote:
>> Suppose for example I have 10,000,000 Friends... I certainly don't want
>> to ever present them all in the UI... secondly, thought I can specify
>> that I want one page from "first" to "first + max", but that does not
>> provide me with any way to tell the UI that there are 10,000,000, so
>> that I can display the total and/or produce a page list...
>>
>> So, like I said, I might just be missing something and/or not
>> understanding the usage of the API (at least from the backend
>> perspective)???
>>
>> It's simply wrong to have to produce the total based on returning the
>> total result set and then pruning out the desired page.
>>
>> i.e. How can I get the total number of "friends" WITHOUT returning them
>> all from the DB? This doesn't seem possible through any of the methods
>> in the backend service tier.
>>
>>
>> Ray
>>
>> On Fri, 2008-04-04 at 10:13 +0200, Cassie wrote:
>>
>>> Which entities are you talking about?
>>>
>>> - Cassie
>>>
>>>
>>> On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <ra...@liferay.com> wrote:
>>>> Hello All,
>>>>
>>>> There does not appear to be a way to return the total number of some
>>>> entity through any of the APIs.
>>>>
>>>> I only see a way of returning a list of entities. Not the total count
>>>> (which I'd need in order to build some pagination).
>>>>
>>>> Perhaps I missed something?
>>>>
>>>> Raymond Augé
>>>> Software Engineer
>>>> Liferay, Inc.
>>>> Enterprise. Open Source. For Life.
>>>>
>>>
>>
>> Raymond Augé
>> Software Engineer
>> Liferay, Inc.
>> Enterprise. Open Source. For Life.
>>
>>
>> Raymond Augé
>> Software Engineer
>> Liferay, Inc.
>> Enterprise. Open Source. For Life.
Re: Returing the total entities count
Posted by Cassie <do...@apache.org>.
The js api supports paging, sorting and filtering. See this page:
http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.PeopleRequestFields.html
The java api supports pagination for the PeopleService for this function:
public ResponseItem<ApiCollection<Person>> getPeople(List<String> ids,
SortOrder sortOrder, FilterType filter, int first, int max,
Set<String> profileDetails, GadgetToken token);
It just doesn't support pagination for the getIds function. We could
add pagination to the getIds function but then that function would
need to know how to sort. But if it needs to know how to sort then it
has to have activity, profile and data info. That doesn't seem like a
really good pattern though.
One possible way to do things would be to get rid of the getIds
function and to have each getPeople, getActivities, getData call
translate the idSpec into a list of ids itself. That eliminates some
of the nice separation that we currently have though.
So, I'm not sure how we want to handle this. Feel free to propose a solution.
Thanks.
- Cassie
On Sat, Apr 5, 2008 at 5:41 AM, Raymond Auge <ra...@doublebite.com> wrote:
>
> There should be some way if providing an integer total from the backend to
> the front end... returning a list of 10,000,000 ids is simply not
> acceptable...
>
> Now, I'm fairly certain that no one will ever have 10,000,000 friends... (I
> certainly don't :) ). BUT... it's more an issue of scalability... It is
> certainly conceivable that I have thousands of events... and it'd be nice to
> be able to get that number without ever having to get them all...
>
> These services need methods to return the total for a given userId.
>
> org.apache.shindig.social.opensocial.ActivitiesService
> org.apache.shindig.social.opensocial.PeopleService
>
> This method needs paging support...
>
> List<String>
> org.apache.shindig.social.opensocial.PeopleService.getIds(IdSpec idSpec,
> GadgetToken token) throws JSONException
>
> This method needs paging support:
>
> ResponseItem<List<Activity>>
> org.apache.shindig.social.opensocial.ActivitiesService.getActivities(List<String>
> userIds, GadgetToken token)
>
> I think this missing functionality extends all the way to the front end JS
> API.
>
> AGAIN... maybe I'm just not understanding it all correctly. If so, can
> someone explain it to me?
>
> Ray
>
>
>
> On Fri, 2008-04-04 at 23:22 -0400, Raymond Auge wrote:
> Suppose for example I have 10,000,000 Friends... I certainly don't want
> to ever present them all in the UI... secondly, thought I can specify
> that I want one page from "first" to "first + max", but that does not
> provide me with any way to tell the UI that there are 10,000,000, so
> that I can display the total and/or produce a page list...
>
> So, like I said, I might just be missing something and/or not
> understanding the usage of the API (at least from the backend
> perspective)???
>
> It's simply wrong to have to produce the total based on returning the
> total result set and then pruning out the desired page.
>
> i.e. How can I get the total number of "friends" WITHOUT returning them
> all from the DB? This doesn't seem possible through any of the methods
> in the backend service tier.
>
>
> Ray
>
> On Fri, 2008-04-04 at 10:13 +0200, Cassie wrote:
>
> > Which entities are you talking about?
> >
> > - Cassie
> >
> >
> > On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <ra...@liferay.com> wrote:
> > > Hello All,
> > >
> > > There does not appear to be a way to return the total number of some
> > > entity through any of the APIs.
> > >
> > > I only see a way of returning a list of entities. Not the total count
> > > (which I'd need in order to build some pagination).
> > >
> > > Perhaps I missed something?
> > >
> > > Raymond Augé
> > > Software Engineer
> > > Liferay, Inc.
> > > Enterprise. Open Source. For Life.
> > >
> >
>
> Raymond Augé
> Software Engineer
> Liferay, Inc.
> Enterprise. Open Source. For Life.
>
>
> Raymond Augé
> Software Engineer
> Liferay, Inc.
> Enterprise. Open Source. For Life.
Re: Returing the total entities count
Posted by Raymond Auge <ra...@liferay.com>.
Suppose for example I have 10,000,000 Friends... I certainly don't want
to ever present them all in the UI... secondly, thought I can specify
that I want one page from "first" to "first + max", but that does not
provide me with any way to tell the UI that there are 10,000,000, so
that I can display the total and/or produce a page list...
So, like I said, I might just be missing something and/or not
understanding the usage of the API (at least from the backend
perspective)???
It's simply wrong to have to produce the total based on returning the
total result set and then pruning out the desired page.
i.e. How can I get the total number of "friends" WITHOUT returning them
all from the DB? This doesn't seem possible through any of the methods
in the backend service tier.
Ray
On Fri, 2008-04-04 at 10:13 +0200, Cassie wrote:
> Which entities are you talking about?
>
> - Cassie
>
>
> On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <ra...@liferay.com> wrote:
> > Hello All,
> >
> > There does not appear to be a way to return the total number of some
> > entity through any of the APIs.
> >
> > I only see a way of returning a list of entities. Not the total count
> > (which I'd need in order to build some pagination).
> >
> > Perhaps I missed something?
> >
> > Raymond Augé
> > Software Engineer
> > Liferay, Inc.
> > Enterprise. Open Source. For Life.
> >
>
Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.
Re: Returing the total entities count
Posted by Cassie <do...@apache.org>.
Which entities are you talking about?
- Cassie
On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <ra...@liferay.com> wrote:
> Hello All,
>
> There does not appear to be a way to return the total number of some
> entity through any of the APIs.
>
> I only see a way of returning a list of entities. Not the total count
> (which I'd need in order to build some pagination).
>
> Perhaps I missed something?
>
> Raymond Augé
> Software Engineer
> Liferay, Inc.
> Enterprise. Open Source. For Life.
>