i am building my the model using ODataModelBuilder, i am trying to create navigation property however in the metadata i dont see any foreginkey indication, in my solution i am not using EF, so there is no foreignKey attribute, is it possible to add it by code?
As you clarified in your comment, the reason you want to add foreign key information is because your client application is not including related entities when you query the main entity. I don't think foreign keys are the problem here.
As an example, I'll use two entity types: Customer and Order. Every Customer has some number of associated Orders, so I have a navigation property on Customer called Orders that points to a collection of Orders. If I issue a GET request to /MyService.svc/Customers(1), the server will respond with all of the Customer's information as well as URLs that point to the related Order entities*. I won't, by default, get the data of each related Order within the same payload.
If you want a request to Customers(1) to include all of the data of its associated Orders, you would add the $expand query option to the request URI: /MyService.svc/Customers(1)?$expand=Orders. Using the WCF Data Services client (DataServiceContext), you can do this with .Expand():
DataServiceQuery<Customer> query = context.Customers.Expand("Orders");
However, WebAPI OData doesn't currently support $expand (the latest nightly builds do though, so this will change soon).
The other approach would be to make a separate request to fill in the missing Order data. You can use the LoadProperty() method to do this:
context.LoadProperty(customer, "Orders");
The LoadProperty approach should work with WebAPI as it stands today.
I know this doesn't answer your original question, but I hope addresses your intent.
*In JSON, which is the default format for WebAPI OData services, no links will show up on the wire, but they are still there "in spirit". The client is expected to be able to compute them on its own, which the WCF Data Services Client does.
Related
I am using the request to GET "/api/data/v9.0/EntityDefinitions" to list all the entities that are present in Dynamics and get basic information regarding them (EntityMetadata EntityType).
I know that some of the entities are standard, custom, non-createable, non-updateable, etc.
To check if an entity is a custom I can use a field named IsCustom from EntityDefinition and if it is true then the entity is custom. But for non-createable entities and others (I don't know how to call them properly) this approach is not applicable, because there is no such field.
For example, 'activitypointer' supports only GET operation (activitypointer EntityType). Records of this type cannot be created. But from the request above, I cannot get the correct information about that.
Can entities be distinguished?
P.S.: maybe I did something wrong and need to look elsewhere?
I've seen a lot of information on the different inheritance strategies but can't seem to find anything on how you setup a REST controller when using a single table strategy. In my scenario, I have 2 Barcode types: product and case.
I created a Barcode superclass that ProductBarcode and CaseBarcode inherit from. However, I have the following questions regarding how to implement this:
Do I need separate repositories for ProductBarcode and CaseBarcode?
Can I use a single endpoint to create/update/delete both kinds of Barcodes?
I have another entity (Product) that relates to Barcode and needs to be able to get the details for a barcode based on an ID. Product won't know what type of Barcode the ID belongs to. Is this something that will cause an issue?
To summarize what I'm trying to do:
Create a barcode entry of either ProductBarcode or CaseBarcode by sending a JSON POST request to a single endpoint such as localhost:8080/barcodes.
Retrieve or update a barcode of either type from a single endpoint.
Be able to perform CRUD operations without needing to know which type of Barcode is being operated on.
Is this something that is doable using Spring Data JPA and Hibernate? Thanks for any advice.
I'm developing a RESTful webservice with spring-data as its data access layer, backed by JPA/Hibernate.
It is very common to have relationships between domain entities. For example, imagine an entity Product which has a Category entity.
Now, when the client POSTs a Product representation to a JAX-RS method. That method is annotated with #Transactional to wrap every repository operation in a transaction. Of course, the client only sends the id of an already existing Category, not the whole representation, just a reference (the foreign key).
In that method, if I do this:
entity = repository.save(entity);
the variable entity now has a Category with only the id field set. This didn't surprise me. I wasn't expecting a save (SQL insert) to retrieve information on related objects. But I need the whole Product object and related entities to be able to return to the user.
Then I did this:
entity = repository.save(entity);
entity = repository.findOne(entity.getId());
that is, retrieve the object after persisting it, within the same transaction/session.
To my surprise, the variable entity didn't change anything. Actually, the database didn't even get a single select query.
This is related with Hibernate's cache. For some reason, when in the same transaction, a find does not retrieve the whole object graph if that object was previously persisted.
With Hibernate, the solution appears to be to use session.refresh(entity) (see this and this). Makes sense.
But how can I achieve this with spring data?
I would like to avoid to create repetitive custom repositories. I think that this functionality should be a part of spring data itslef (Some people already reported this in spring data's forum: thread1, thread2).
tl;dr
References between entities in the web layer need to be made explicit by using links and should not be hidden behind semi-populated object instances. References in the persistence layer are represented by object references. So there should be a dedicated step transforming one (the link) into the other (the fully populated object reference).
Details
It's an anti-pattern to hand around backend ids as such and assume the marshaling binding doing the right thing. So the clients should rather work with links and hand those to the server to indicate they want to establish a connection between an already existing resource and one about to be created.
So assuming you have the existing Category exposed via /categories/4711, you could post to your server:
POST /products
{ links : [ { rel : "category", href : "/categories/4711" } ],
// further product data
}
The server would the instantiate a new Product instance, populate it with additional data and eventually populate the associations as follows:
Identify properties to be populated by looking up the link relation types (e.g. the category property here.
Extract the backend identifier from the given URI
Use the according repository to lookup the related entity instance
Set it on the root entity
So in your example boiling down to:
Product product = new Product();
// populate primitive properties
product.setCategory(categoryRepository.findOne(4711));
productRepository.save(product);
Simply posting something like this to the server:
POST /products
{ category : {
id : 1, … },
…
}
is suboptimal for a lot of reasons:
You want the persistence provider to implicitly persist a Product instance and at the same time 'recognize' that the Category instance referred to (actually consisting of an id only) is not meant to be persisted but updated with the data of the already existing Category? That's quite a bit of magic I'd argue.
You essentially impose the data structure you use to POST to the server to the persistence layer by expecting it to transparently deal with the way you decided to do POSTs. That's not a responsibility of the persistence layer but the web layer. The whole purpose of a web layer is to mitigate between the characteristics of an HTTP based protocol using representations and links to a backend service.
I'm reading the book "Architecting Applications for the Enterpise (Dino Esposito)". It raised a question about validation.
The Domain Model can have a property CanBeSaved which calls the Validate() method of the Domain Model. All good, except for complex situations.
For example a Customer model which needs a unique customer code (ex. 000542). You can only check this with database access. Isn't it better to put the Validation always in a Domain Service. So you have only one way of checking if an aggregate is in a valid state? If you use both, a developer can 'forget' to use the domain service validation for the Customer.
I find it better to have always valid entities rather than rely on an external validation object.
That being said, unique checks are a bit of an exception since it is often not something that the aggregate itself can determine on its own, you have to look into all existing aggregates to see if the value is not already taken. What I do is check for availability of the value before creating the entity, and also put a constraint in the database which will verify uniqueness at persistence time. You could also try to find a domain concept that encompasses all your entities and make it an aggregate that has a list of all codes and enforces the uniqueness invariant.
I've made a custom entity that will work as an data modification audit (any entity modified will trigger creating an instance of this entity). So far I have the plugin working fine (tracking old and new versions of properties changed).
I'd like to also keep track of what entity this is related to. At first I added a N:1 from DataHistory to Task (eg.) and I can indeed link back to the original task (via a "new_tasksid" attribute I added to DataHistory).
The problem is every entity I want to log will need a separate attribute id (and an additional entry in the form!)
Looking at how phone, task, etc utilize a "regardingobjectid", this is what I should do. Unfortunately, when I try to add a "dataobjectid" and map it to eg Task and PhoneCall, it complains (on the second save), that the reference needs to be unique. How does the CRM get around this and can I emulate it?
You could create your generic "dataobjectid" field, but make it a text field and store the guid of the object there. You would lose the native grids for looking at the audit records, and you wouldn't be able to join these entities through advanced find, fetch or query expressions, but if that's not important, then you can whip up an ASPX page that displays the audit logs for that record in whatever format you choose and avoid making new relationships for every entity you want to audit.
CRM has a special lookup type that can lookup to many entity types. That functionality isn't available to us customizers, unfortunately. Your best bet is to add each relationship that could be regarding and hide the lookups that aren't in use for this particular entity.