I have a Product object with a property that is a collection of type Workflows. In my "GetProducts" method on the domaincontext object I have set a breakpoint at the return statement to see if the workflows collection is filled.
It is.
On the client side I check Context.Products[0].Workflows in another breakpoint and I see 0 results. Is there a way to persist this nested data for consumption on the client side or is RIA Services inhibited from doing this?
If you have or can download the RiaServicesOverviewPreview.pdf document section 4.8 details how to do this. The basic summary it.
Make sure your L2S query specifies the .LoadWith<>() parameter. Lazy loading doesn't work with RIA services so you have to use implicit loading.
You need to apply the "IncludeAttribute" to the associated member. For example add the [Include] attribute on your Workflows field in the Product metadata class.
Ensure that your Workflow (child) type is exposed as a client type so it gets genned to the client side.
You can get the document here: http://www.microsoft.com/downloads/details.aspx?FamilyID=76bb3a07-3846-4564-b0c3-27972bcaabce&displaylang=en
I should kick myself. I realized that I needed to add "[Include]" to the property in Product within the DataService.metadata.cs file and now it gets sent to the client.
Related
We are implementing CRUD interface to manage entities with SOAP messages. What are good practices to allow partial updating of the entity? Meaning the client could update just some attributes of the entity, without having to post the whole entity? Is there more general approach to this than distinct methods for each attribute update?
HTTP Patch can be used for partial updates, only sending the fields of the object you want to change. There's an interesting discussion about partial updates here.
I'd say it would be more important to make sure the partial update is idempotent, i.e. the same update fields in the request result in the same end state of the resource. So if you have internal logic that determines the state of a resource attribute based on the value of another resource attribute that is being updated that might be something to look into. e.g. if the resource as a whole has rules for when parts of it are updated but other parts are not specified (default values for some attributes?), that may cause different outcomes based on the current state of the resource.
If the resource as a whole is just a collection of unrelated attributes then partial updates make sense but if there are dependencies among some attributes and some get updated while others don't, then the end state of the resource has to be idempotent. e.g. does it make sense to update an address but not update the phone number? What happens to the phone number if it's a landline and the address gets updated? Is it set to null? and vice versa. So when doing partial updates it might be worth 'partitioning' the allowed partials based on the domain being updated.
We are building a RESTful web service where there are sometimes different required fields for a POST than a PUT. For example, a field like CustomerSinceDate is allowed to be set on an insert, but not on an update. Is there is a way to set that up with Data Annotations?
EntityFramework does not (and should not) know anything about your web service. It deals only with what rules exist in the persistence layer.
What you are looking for is validation.
So in your REST service, you should check whether CustomerSinceData has been changed, and the entity is being updated. If so, you should throw an Exception with an appropriate message to the consumer.
Here is an article on writing your own DataAnnotations, if you prefer using those:
http://msdn.microsoft.com/en-us/data/jj819164#attributes
Otherwise, take a look at this article on how to write your own custom validation: http://msdn.microsoft.com/en-us/data/gg193959.aspx
(in particular, the section on IValidatableObject).
Your rule could be formulated as (pseudo code)
//if object exists in db AND CustomerSinceData has changed
DataAnnotations will get you a long way, but can be tedious to write if you are writing business logic that will never be reused anywhere else.
So far i understand that i will have no more need to define an #version field in my entitites and no more need to use an entity locator. And for value proxies i will have to usenormal editors. Any other diffrences, advantages, disadvantages? What about in the context of using request factory in conjunction with spring
The main difference is that with EntityProxy, the client can send a diff of changes rather than the entire object graph. This is made possible because EntityProxys have an identity, so the server can fetch the identity from the datastore and then apply the diff/patch sent from the client, and only then the entity will be passed to your service methods.
With ValueProxy you basically have an equivalent of GWT-RPC: the object is reconstructed from scratch on the server, and not associated with your datastore (in the case of JPA for instance, it's not attached to the session). Depending on your datastore API, this can make things more complex to handle in your service methods.
Other than that, you'll also lose the EntityProxyChange events.
Trying to persist an entity which contains a member variable that is a reference to some other entity which is not under the current persistence context will not be possible, when this happens one needs to fetch the required entity and set it in the original entity in order to respect the relationship and be allowed to persist it.
When I need to accomplish this I usually make use of the EntityManager's find method, but that will hit the database and fetch the entire entity along with it's relationships that may not be annotated for lazy loading. I was happy to find out about getReference, which suposedly won't hit the database but return a proxy representation where only the primary key is available and that is really all that is required for this type of situation.
Unfortunately after some debugging I find myself being able to view all the information about the getReference'd entity and not just the primary key when I "inspect" it via Eclipse debug mode.
Am I missing something? Am I being deceived by the debug mode? Could it be fetching the information like a getter method would when used on the proxy reference?
Thanks in advance
Whe you inspect it using the Eclipse debugger, the debugger initializes the proxy. Just turn on SQL logging, execute the em.getReference() method, and verify that no select statement has been executed by your JPA engine.
I am having trouble getting related entities to be loaded on the client using RIA Services and EF 4.1 with Silverlight.
I'm currently using the Include() method on my DbDomainService with an Expression parameter and am finding that when stepping through my service the related entities are loaded just fine. However, when the Queryable results are returned to the client NO related entities are loaded - they are null. All of my entities are marked with the [DataMember] attribute so I have assumed that it isn't a serialization issue. Moreover, my DbDomainService query method is marked with the [Query] attribute.
I was wondering if there is anything specific that has to be set up on the client when using RIA Services with EF 4.1 code first? I must be missing something, but I'm not sure what.
Any help would be appreciated.
Thanks,
sfx
While you may have used the .Include() in your service call, you also have to add the [Include] attribute in the metadata class that is also created.
The .Include() statement tells EF to generate the SQL necessary to retrieve the data, while the Include attribute tells WCF RIA Services to make sure the Entity Class is also created on the client.
Once the data arrives at the client, it needs to know what type of structure to put it in as well.
HTH