That's correct. We have a services layer that can return userids based on
certain criteria and another that can look up basic or extended user
information given lists of IDs.
Assume you have a NativeUser object, you need to convert that to Person
objects. The basic logic goes like this:
* Given a query with a FILTER, SORT, LIMIT, OFFSET
* If FILTER is present map to compatible service layer call to only
fetch those IDs.
* Pass SORT to services layer if supported.
* If IDs are sorted grab the sublist of IDs based on LIMIT/OFFSET, retain
totalnumber
- If not, fetch basic objects that have just enough information to
execute a sort.
- Sort, using native sorting methods if available. Also use a top-n
sort routine if that's available.
- Apply LIMIT/OFFSET
* Pass each ID or native object to a conversion routine with the a list
of required fields, only fetch data that is requested.
* Create a collection
This differs from the existing implementation which is basically:
* convert everything to a Person
* Sort the Person objects
* Apply FILTER
* Apply LIMIT/OFFSET
* Return collection.
For people with many, many friends this is very inefficient.
On 4/9/08 11:03 AM, "Raymond Auge" <[EMAIL PROTECTED]> wrote:
> My interpretation is that he has a "User" model which is a little
> different than what is defined in the openSocial Person model.
>
> Like him, we have to "convert" our "User" to a "Person", which actually
> involves a couple of different tables, so cost is always a concern.
>
> What I'd like to hear is a brief outline of filter/fetch optimizations
> Paul used to translate the "first/max/sort" to queries?
>
>
> Thanks,
>
> Ray
>
>
> On Wed, 2008-04-09 at 10:51 -0700, David Primmer wrote:
>
>> On Wed, Apr 9, 2008 at 5:08 AM, Paul Lindner <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> For the SocialData API stuff we integrated the various calls with our
>>> existing User/Friends/Activity services. We spent a bit of time
>>> optimizing the People fetches to only convert users that fall into the
>>> resultset. The trick is to convert filters into appropriate backend
>>> calls to reduce the data set size, and then to intelligently select only
>>> the actual users to convert based on first/max/sort
>>
>> Great email Paul. Could you elaborate on what 'convert' means? Are you
>> saying that you had some data transformation logic that you needed to
>> put at the right layer and you had to move it closer to the front end?
>> What do you mean by 'convert filters'. Are these filters in the social
>> APIs?
>>
>> davep
>>
>
> Raymond Augé
> Software Engineer
> Liferay, Inc.
> Enterprise. Open Source. For Life.
