Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] IdAS interface questions


 
Not exactly. Actually we want to call getEntity() once per unit of work but have provider loaded only needed attribute values of Entity itself as well as only needed attribute values of included complex values, not more. Yes, in this case CP don't need to do unnesessary protocol roundtrips inside (#2).
We propose to change method signature to getEntities(IFilter filter, IAttributeSelection attrSelection) and getEntity() respectively, where IAttributeSelection with companion interfaces would be something like the set of Filter interfaces. Instance of it can hold the tree structure of only needed attributes and complex value's attributes according to actual model of Entity and owl schema. It would be something very simple like this:
 
interface IAttributeSelection {
    addAttribute(URI attrType);
    addComplexAttribute(URI attrType, IAttributeSelection selection);
}
 

Thanks and regards.

Yuriy.

 

----- Original Message -----
Sent: Friday, May 23, 2008 10:15 PM
Subject: Re: [higgins-dev] IdAS interface questions

So, I'm not exactly sure what's being asked for. What is the actual problem?:

1) It takes too many API calls to access all values of all attributes

2) Too many protocol hits happen (inside the CP) when accessing all values of all attributes


If it's #2, I think there are things we can do about it.  If it's #1, what do you suggest?  The fact is that the Higgins Data Model drives the APIs.


You ask for "interfaces that will not need cycles and big number of separate calls".  I'm not sure how to do this unless we decided to serialize an entity and it's attributes and values (recursively) into some formated blob (like structured XML) and return that instead of objects that need to be traversed.  Is that what's being suggested?  If so, what will people do with that?  Most people will parse it and then use DOM APIs to traverse the tree of elements.  How is that different from what the existing Higgins APIs do?


Jim

>>> "Yuriy Pilipenko" <ypilipenko@xxxxxxxxxxxxxx> 05/22/08 10:10 AM >>>

Hi, Paul.

Yes, inside provider we can get all the Entity information, cache it and return it by one piece at a call. Ok, when the Entity contains very big volume of information, such as Attribute with many simple values (collection), we can narrow the result by specifing only needed attributes. But how can we limit the needed info if the Entity contains some attributes with complex values which in turn can hold also complex values with their respective attributes as well as simple attributes with collections of simple or complex values wich in turn... and so on. Such Entities can be resource-intensive when loading in whole.

How can we specify loading not entire Entity but only needed info in the attributes of complex values? Now it can't be done. It may be possible when Iterfaces will become changed to use IEntity instead of IComplexAttrValue and adding probably getEntities(IFilter filter, Iterator attrSelectionList) method to IAttribute interface for example. However it still will require one separate call per such an Attribute with complex values - Entities. In this case provider may not load Entity's complex values at once when getting Entity.

Thanks and regards.

Yuriy.

----- Original Message -----

Sent: Thursday, May 22, 2008 2:59 AM

Subject: RE: [higgins-dev] IdAS interface questions



We have had some conversations today about this. In brief there is a great deal that can be done in the CP to vastly improve performance. For example each call to get an attribute value of an Entity doesn’t imply that a SQL query (or LDAP query) is done. Quite the contrary, the entire Entity should be fetched from the backing store with one query and then this Entity responds from memory to each fine-grained get attribute call.

 

Back to the top