I understand that in usergrid UI I can create an Individual collection , but it does not allow me to create a collection under a collection. Is there a way of doing that . Otherwise we will be forced to write business logic in the proxy layer which we don't want to do.
With Regards
-S
There is no concept of subcollection, but you can use connections. So you can do something like this:
POST cats/fluffy/hasa/toys/ball
The above would mean that that an entity of type "cat" is connected to an entity of type "toy" that is called "ball" by a connection verb "hasa".
You can also store sub-objects in an individual entity (e.g. full JSON is supported). If you want to describe your use-case a bit more, I can maybe recommend other ways to structure your data.
Related
I'am new in Olingo: sorry if my question is strange.
When Olingo service receive request to get entity of EntitySet_1 it calls method of custom entityProcessor (then processor call some storage object and send to it EdmEntitySet and List objects). But this processor method must get entity of EntitySet_2 to end processing. How i can realize getting entity of another entitySet? Or in other words: how can i get entity of another entitySet programatically (is it necessary to create new EdmEntitySet object? etc.) ?
Maybe some ideas, clever words...
Found only one solution: REST-request to the same service for entity of EntitySet_2 while processing entity of EntitySet_1.
Such feature should comes from the design itself. Calling same service from itself is not recommended.
What you should do is utilize the data access methods (ex:- database access method) you already have and get the required EntitySet_2 from it for processing.
For this you will need to create data access requests (ex:- SQL query for EntitySet_2) and map the results to create the EntitySet_2. As I said earlier, the design of your service should be flexible enough for this.
https://facebook.github.io/relay/graphql/objectidentification.htm is very clear around what Node is and how it behaves, but it doesn't specify which objects must implement it, or what the consequences are if your object doesn't implement it. Is there a set of features that don't work? Are such objects completely ignored? Not all objects in the existing spec (e.g. pageInfo) implement it, so it's clearly not universally required, but pageInfo is somewhat of a special case.
Another way of thinking about the Node interface is that objects that implement it are refetchable. Refetchability effectively means that an object has an ID that I can use to identify the object and retrieve it; by convention, these IDs will usually be opaque, but will contain type information and an identifier within that type (eg. a Base-64 encoding of a string like "Account:1234").
Relay will leverage refetchability in two ways:
Under a process known as "diffing", if you already have some data for an object identified by ID QWNjb3VudDoxMjM0 (say, the name and address fields), and you then navigate to a view where we show some additional fields (location, createdAt) then Relay can make a minimal query that "refetches" the node but only requests the missing fields.
Relatedly, Relay will diff connections and will make use of the Node interface to fill in missing data on those (example: through some combination of navigation you might have full information for some items in a view, but need to fill in location for some items within the range, or you might modify an item in a connection via a mutation). So, in basic pagination, Relay will often end up making a first + after query to extend a connection, but if you inspect its network traffic in a real app you will also see that it makes node queries for items within connections.
So yes, you're right that pageInfo doesn't implement Node, and it wouldn't really make sense for it to do so.
Is it possible to update entity properties corresponding to collections of primitive and complex types without sending all the content?
For example, for an entity Question that has a property tags corresponding to a list of string:
POST /OData.sac/questions/tags to add an element to the list
DELETE /OData.sac/questions/tags with the value as query parameters to delete it from the list
and something similar for complex types.
Such mechanism is supported for navigation properties.
Thanks very such for your help!
Thierry
Unfortunately it's not currently possible to partially update a collection property. It's something we thought about a lot and it's something we knew we would get asks for, but we just couldn't make the tradeoff work. To fully support partial updates we would need to have a way to identify individual members of a collection. This doesn't exist yet.
We are considering at least allowing the two operations (create and delete) you've suggested above in OData 4.1. See issues 615 and 616 in the OASIS issue tracker.
I have a n-tier solution with these projects in it (simplified for this question):
Domain
Logic
Web
In the "Domain" project I have a "Repositories" namespace and each repository is mapped to a different table in the DB and query its data.
For example - the tables Customers and Orders will have the corresponding repositories - CustomersRepository and OrdersRepository.
In the Logic project I instantiate these repository objects and call their methods which actually query the DB.
Lets say I want to show a report that display some data from both tables.
This report is constructed by a collection of custom objects - IList<ReportObject>.
Now, this ReportObject object has no corresponding table in the DB and therefore has no repository object.
My question: Where should I put the part of code that actually query the DB and fetch IList<ReportObject>? Should it just be in some data controller in the Logic layer? or create another repository for the reports? Any other option?
While I think this is mainly a question of opinion, here goes:
You can create a QueryStore<ReportObject> instead of a Repository<ReportObject>. The name QueryStore is just something I came up with, it's not a coined term.
The function of such a query store would be to, well, run queries on data that is not covered by any repository. It would contain only queries and so can, for instance, easily be implemented using LINQ on top of Entity Framework querying database VIEWs for instance.
I'd put it in a custom repository (as this is not a CRUD operation). You can extend Repository (if you're working with a generic repository) and create one for the query. I wouldn't put queries in other place rather than Repositories since you'll brake the encapsulation of what Repository does. Imagine you change the database in the future, it won't be enough to change the repositories layer. Another reason to not put it there is that the logic will be spread around the application instead of being everything in just one place which simplifies debugging and improvements in the queries.
Hope it helps. Guillermo.
The repository pattern is used to encapsulate CRUD operations, but in your case you do not need any Insert or Update. I would put this into the Logic layer and access the DB directly from there.
I am working on a large project at work that requires me to create OData's for a large variety of Remote Function Calls. I was able to work out how to model and create OData's for simple RFCs; however, I am struggling with more complex RFCs that use multiple tables as well as simple exporting and importing parameters.
I want to output these tables as well as the importing and exporting parameters via GetEntity and GetEntitySet with just one call. I have done extensive searching online to find solutions but the best solution seems to be redefining the RFC's or calling the OData multiple times which is not ideal.
Is there any way to combine multiple tables with several entries in the output? When I say output, I am referring to the resulting XML from GetEntity/GetEntitySet.
For example, take the below fake RFC definition that takes a PERNR, and outputs a list of direct reports and a structure of employee details.
IMPORTING
PERNR
EXPORTING
S_EMPLOYEE_DETAILS
TABLES
T_DIRECT_REPORTS
Is there a way to combine the table, structure, and importing parameters into one output?
The first thing to understand is that the OData protocol is not intended to solely work like classical function calls. It is based however on entity/relationship kind of model.
So in your case id sugest to create an entity type named 'Employee' with the appropiate properties of your structure S_EMPLOYEE_DETAILS. With this you can e.g. implement the method GET_EMPLOYEE_ENTITY to retrieve a single instance of an employee via PERNR.
The next thing to do would be to get the direct reports of this employee. Since this is a relation 1:N from Employee to Employee in your case you can create a navigation property called 'DirectReports' with appropiate cardinality. Then in your GET_EMPLOYEE_ENTITYSET you can return the instances of table T_DIRECT_REPORTS (note that navigation property is not empty and you have to read the keys of the parent!).
Once you got this working you can move on to the 'best-practise' and implement the method GET_EXPANDED_ENTITY with filling the expand clauses, which is in my opinion the preferred way as you dont need to implement two seperate methods and is consiered faster as well (if many expands happen).
Both methods of implementation can be called via
GET EmployeeSet('12345678')?$expand=DirectReports