In Fiware, entities are identified by two fields: entityId + entityType. This means that you can have multiple entities with the same entityId while its have differents entityType.
Said that:
-How it is accepted to create entities using ngsi10 convenience operations in which entities are created with an empty entityType field?
-Is it unrecommended to created entities that way?
It is perfectly possible to create entities using convenience operations. A section in the manual describes the topic. In this sense, it is as recommended as creating entities using standard operations is.
In fact, Orion is quite flexible and there are 3 ways of doing that:
Using POST /v1/contextEntities/Room1. The entity ID is specified in the URL, the entity type is "empty type" (i.e. "").
Using POST /v1/contextEntities/type/Room/id/Room1 (since Orion 0.16.0). Both entity ID (Room1) and type (Room) are specified in the URL.
Using POST /v1/contextEntities (since Orion 0.17.0). In this case both entity ID and type are specified in the payload.
Related
I am building a REST API which creates a resource. The resource has only one attribute which is a rather long and unique string. I am planning to send this data to the API as JSON. I see two choices for modeling the data as JSON
A primitive JSON String data type
A JSON object with one String attribute.
Both the options work.
Which of these two options is preferred for this context? And why?
Basic Answer for Returning
I would personally use option 2, which is: `A JSON object with one String attribute.'
Also, in terms of design: I prefer to return an object, that has a key/value. The key is also a name that provides context as to what has been returned.
Returning just a string, basically a "" or {""} lacks that context ( the name of the returned variable.
Debate: Are primitive Strings Json Objects?
There seems to be also some confusion as to if a String by itself is a valid JSON document.
This confusion and debate, are quite evident in the following posts where various technical specs are mentioned: Is a primitive type considered JSON?
The only thing for sure is that a JSON object with a key-value pair is definitely valid!
As to a string by itself.. I'm not sure ( requires more reading).
Update: Answer In terms of creating/updating an entity (Post/Put)
In the specific case above, relating to such a large string that "runs into a few kilobytes"... my feeling is that this would be included within the request body.
In the specific context of sending data, I would actually be comfortable with using either 1 or 2. Additionally, 1 seems more optimized ( if your frameworks support it), since the context about what the data is, is related to the rest API method.
However, if in the future you need to add one more parameter, you will have to use a JSON entity with more than one key.
I have a complex many-to-many relationship defined. The cross-reference table is an entity, so I have Contact with a One-To-Many to ContactList, and List with a One-To-Many to Contact List. Contact List contains listID, contactID, and a few Booleans. The relationships seem to work well and on the backend I can get a list of contacts on a review list using the Spring-Data-Jpa findByContactListsIn(Set).
However, I am trying to build a list of contacts in Freemarker, and show whether they were in the current list.
Before I made an Entity out of ContactList, I had a standard Many-To-Many relationship between them, and I was able to do something like this in my .ftl:
<#if list.contacts?seq_contains(contact)>
But I needed to add some data to ContactList specifically, so I needed it to be more complicated. How can I do something similar now? I tried:
<#if list.contactLists?seq_contains(contact)
But of course that always returns false, because it is comparing two different entity types. Is there a way to find if a contact is in one of the contactList objects?
I suppose I could do some back-end trickery, but I am looking for a front-end solution to this.
Don't use ?seq_contains for finding generic object at all. It doesn't call Object.equals, instead it works like the == operator of the template language, which only allows comparing strings, numbers, booleans and dates/times, otherwise it gives you an error. Unfortunately it won't fail in your case, because POJO-s are also strings (and their string value is what toString() returns). This is an unfortunate legacy of the stock ObjectWrapper (scheduled to be fixed in FM3); not even a quirk in the template language. Ideally you get an error there. Instead, now it silently compares the return value of the toString()-s...
Your data-model should already contain what the template should actually display. FTL is not a programming language, so if you try to extract that from the data-model in it, it will be a pain. But, that the data-model contains that data can also mean that some objects in the data-model have methods that extract the data you need. As a last resort, you can add objects that just contain helper methods.
Update: Returning to ?seq_contains, if you need the Java semantics and list is a Java Collection, you can just use the Java API: list?api.contains(contact).
I have an object model with a parent -> children relation:
class diagram
The relation is a composition, a parent can have multiple children, a child has always one parent and cannot live without its parent. To persist this data, we serialize it into JSON and use a NoSQL document database (MongoDB) to store it:
{
"id": 123456,
"Attr1": "I'm a parent",
"children": [
{
"Attr1": "I'm a child"
},
{
"Attr1": "I'm another child"
}
]
}
Now we are trying to map this model to an OData EDM. We map the parent objects as an entity type. Because the children cannot live on their own but are rather part of the parent we did not want them as entity type but more like a complex type.
When using OData 2, I am having a hard time, because OData 2 seems to not know about collections of primitive or complex types. As soon as you need to map a "to many" relation, it seems necessary to define the "many"-side of the relation as an entity type in its own right. But when defining the children in my model as an entity type, OData2 requires to be able to address these children on service root level.
So the canonical URL of the following object
httX://host/serviceroot/Parent(1)/Child(2)
really is something like this:
httX://host/serviceroot/Child(1,2)
See documentation of OData2:
"For OData services conformant with the addressing conventions in this section, the canonical form of an absolute URI identifying a single Entry is formed by adding a single path segment to the service root URI. The path segment is made up of the name of the Collection associated with the Entry followed by the key predicate identifying the Entry within the Collection. For example the URIs httX://services.odata.org/OData/OData.svc/Categories(1)/Products(1) and httX://services.odata.org/OData/OData.svc/Products(1) represent the same Entry, but the canonical URI for the Entry is httX://services.odata.org/OData/OData.svc/Products(1)."
http://www.odata.org/documentation/odata-version-2-0/uri-conventions/
For me, OData 2 seems to fit for relational databases, where when objects are connected with a "to many" relation, they are mapped to different tables and every object therefor has its own primary key. In this case, it is easy to address a child object on service root level (httX://host/serviceroot/Child(48346954) (where 48346954 is the DB primary key)) because you can fetch that object directly with SQL means.
However, OData2 seems not to fit for document databases which can store nested object graps as documents (e.g. JSON). Child objects do not need to be independent documents but are rather nested in the parent document. When mapping this to OData and then address a concrete child, you would need to first find the document in which this child is embedded and from there traverse the object graph to the child. A direct fetch of an embedded child is not possible.
What do you think, am I right when stating that OData 2 does not really fit a document oriented database?
When using OData 4, things change a bit, because OData 4 knows about collections of complex types. So may be I can model my children as complex types. Then I have the "to many" relation of parent to its children as a property of the parent with type "complex collection". Would this be the recommendet way to model dependent and nested child objects?
Is OData 4 better suited to map documents from a document oriented database to a REST interface? Has anyone tried it? Or are there more pitfalls I currently do not see and that make OData 4 not a good choice in my case?
I have two entities X and Y with the relation #ManyToMany. X has a list of Y's, let's call it yList. Both X and Y has other class members as well (they are not important).
I am using Hibernate as JPA provider, and jackson-databind / jackson-annotations for things like serialization and deserialization.
Now, the following json is received from the client. It has all the fields of X, but only a list of id's for Y. As a concrete example, X could be Person and Y could be Country. And the many-to-many relation captures which countries have been visited by whom.
{
name: 'Bob Dylan',
age: '74',
visitedCountryIds: ['45', '23', '85']
}
When deserializing this json, I want to populate all the fields of the entity X, including yList, such that the elements of yList are resolved by looking up these entities in the database.
My idea so far is to deserialize yList by writing a custom subclass of JsonDeserializer, and have it perform the lookup by id.
Is this a reasonable approach?
You could use #JsonCreator (as already suggested by Uri Shalit) or just a setter method for your property in which you would do necessary lookups from the database.
However, if you have many entities (and associations) for which you want to do this, then this could be a repeated boilerplate code. Also, if implemented in entity classes directly, it would pollute them with database lookup code (readability, SRP, etc).
If you want some generic approach to this, then I think you are on a good way; custom deserializer is the place to implement it.
If I were to implement the generic approach, I would probably introduce a custom annotation which I would place on the association definition together with standard JPA annotations. For example:
#MyCustomJsonIds("visitedCountryIds")
#ManyToMany(...)
private List<Country> countries;
Then, in the deserializer, I would query for the presence of those annotations to dynamically determine what needs to be looked up from the database.
Another option is to create a constructor that that accepts those parameters, annotate it with #JsonCreator and have the constructor perform the lookup from the database, this way you don't need to write a specific deserializer.
I have a User entity with too many relations to other entities in the system. And I am using AngularJs and want to serialize the User entity to json with only the included entities.
Here is my select statement:
var users = unc.Users.Include("Profile").ToList();
when serializing this to json it will always result into
The operation cannot be completed because the DbContext has been disposed
I used to solve this problem by just selecting every column I need in my view like this:
var users = unc.Users.Select(x => new { x.Id ,x.Username,Role=x.Role.Name,x.Email,x.Profile.Name,x.UpdatedAt,x.CreatedAt}).ToList();
but this is too hard and much code to write. I am looking for the ideal or a better solution.
Thanks
I'v found a decent solution here.
https://efjson.codeplex.com/
This will serialize your entity without including related entities unless you wanted to include those entities. This will avoid entering into circular loops caused by entities calling each other back through reversed attributes.
Also serializing related entities you want will make it easy to serialize an entity and through the JSON back to scripts like AngularJs.
Hope this will make other people happy too :)