• ADDED: Uniquing Context, which provides a unique object per loaded entity, so entity data which is fetched multiple times with the same context will result in the same entity object.

are we talking about object caching here. Can you pleas elaborate on this

omar wrote:

• ADDED: Uniquing Context, which provides a unique object per loaded entity, so entity data which is fetched multiple times with the same context will result in the same entity object.

are we talking about object caching here. Can you pleas elaborate on this

Yes, it's a cache, it's a cache per editing context . You shouldn't use it for caching objects which should live for a long time, as that requires a different kind of cache. This cache is used for having unique objects in a given context, for example in a BL process: using the same context ensures the same entity objects are used so if you fetch customer CHOPS twice, you get the same object, as teh context holds one after the first fetch.

As you can do in code: CustomerEntity c = new CustomerEntity(); and then fetch it with data, to keep the same entity object (c is a new instance here), you have to ask the Context for the proper instance, given the data. So it doesn't necessarily limit data fetches, it only does when you have a single entity request and you know it's already in the Context, you can then call Context.Get(factory, pk values) and it tries to find it for you, and if not, it will return a new one for you with the PK fields filled in.

You can have multiple contexts per adapter for example, so it's up to you what you define as 'unique context in which an entity object has to be unique'. Often you don't need this, so I made it an optional object. Uniquing contexts aren't new, the idea of having editing contexts (multiple if you want) is ripped from teh Apple business objects framework

With these contexts you can refetch prefetch paths and get the same objects and for example a new child tree fetched into them. Without a context this isn't possible.