Handling reference objects in the Disconnected API

[James Denning]

Hi
I am using the disconnected API ObjectContainer over WCF and am encountering issues with attaching reference data objects that are persisted by OA to other OA-managed  objects when working via an ObjectContainer. I wonder if someone can advise.

A sample scenario would be where you have a Person object which I am creating, to this I add a new Address object. The address object has a Country field to which I attach a Country object which is an OA-managed class that i have requested within a list from the server (have tried via Container, ChangeSet or straight list from a Scope on the server). Problems arise when I try to commit the changes to the Container (examples of errors included "NotImplementYet: GetReferencedObject: SCO", "Object is already Detached"), or if I send the new object back to the server to be added via a Scope then the Scope does not recognise the Country object as an existing object and tries to recreate it leading to duplicate key errors.

What would be the best way to handling readonly reference data objects on a disconnected API client? FOr example I do not want these items locked but I need the container i am using on the client to know about them so I can add them to new or existing business objects.

Cheers
James

[Alexander]

Hi James,

If I understood you correctly - you want to create new object on the client side and assign to one of its references an existing Country object. To achieve this you will have to load the list of necessary Country objects within an ObjectContainer on the server side. Then get the ChangeSet from this container and send it through the service. On the client side apply the retrieved ChangeSet to the ObjectContainer of the client. Now create an Address object and set the appropriate Country object there. To get a particular Country instance from the container you can execute a query or use the ObjectContainer.GetObjectById() method:

container.Transaction.Begin(); Country c = (Country) container.GetObjectById(Database.OID.ParseObjectId(typeof(Country), countryId.ToString())); Address a = new Address(); a.Country = c; container.Add(a); container.Transaction.Commit();

After calling container.Transaction.Commit() the newly added Address object will be stored in the container. To persist it to the database, get the ChangeSet from the container, send it to the server and apply the changes there. Hope this helps.

All the best,
Alexander
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[James Denning]

HI there
Many thanks for your prompt reply - I got this working though I have some additionalconcerns:
1. ObjectContainer size on the client - I am presuming this can act as a de facto caching object though I have to manage the cached content using the Evict method. Is there any guidance on this? Or should I generally use non-containerised objects got from the server (i.e. straight from Scope to the client via WCF, not via a container and changeset) and then only containerise those objects i need to attach to entities?

2. Locking - if multiple clients get the reference data objects from the server is there any way to ensure there is no  locking when detached (for example marking the server side cotnainer from which i will get the list of objects as IsReadOnly=true)?

James

[Alexander]

Hello James,

1. The major functionality that you would lose if using detached objects is the change tracking of the scope/container. You will need to implement custom logic on the server to check whether the objects have been changed and if so, load the actual objects stored in the database and copy the changes to them. Having an object container on the client is not a big overhead than just having the detached objects there. You can indeed use the Evict method to control the size of the container and clean it from the unnecessary objects. Note that this method accepts an IEnumerable of persistent capable objects as well as single objects. That could speed up the cleaning.

2. I do not think you need this at all. By default OpenAccess does not set any locks to the retrieved objects. In the case of using ObjectContainers, the concurrency mechanism is triggered at the last step - when applying the changes back to an ObjectScope. There you can set the level of concurrency control to be used. And if there are any (conflicting) changes made, you will be able to handle them.

Sincerely yours,
Alexander
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[James Denning]

Thanks for the very helpful reply.