The docs only mention that GroupResult is "Like ResultSet, but with an associated id."
Specifically, when would it be suitable to use ResultSet instead of GroupResult if the only difference is GroupResult has an id?
You use ResultSet when you have multiple AsyncResult objects from different tasks that you want to deal with all at once. GroupResult on the other hand is what you use instead of AsyncResult when you executed the Group primitive and want to query what is happening with the tasks in the group. That is why it has an associated ID - because the Group will have a task-id associated to it.
Related
I have a persistent actor which holds some values. I need to get some filtered ones of them. So, I have two ways:
1) Create new message say
GetValuesWithNameAndAgeGraterThan(name: String, age: Int)
pro: immutable, orthodox :)
contra: the problem here is that logic leaks into persistent actor which should be responsible only for keeping and providing data and ya, this case is exactly fits to providing data definition. But why should it know about "name" and "age" of value it keeps?!
And since tomorrow I would be needed to add more and more messages which would become a mess at the end.
2) Create generic message with filtering predicate
Filter(p: Value => Boolean)
pro: single, scalable, immutable when used properly
contra: I see the only problem when someone does
val ages: mutable.Seq[Int]
persistor ? Filter(v => ages.contains(v.age))
ages += 18
ages += 33
but we are usually using immutable values in Scala!
and also it would be unnatural to try to persist lambda, but we use it for read only!
So, what do you think?!
Never do follow the second approach!
The first is valid, but id change this a little bit.
You could initially agree on some contract for stored data, e.g might be an Enumeration where each value carries a value type.
So you modify your message with
GetValueForCondition(conditions: Seq[DataType, filter: Value => Boolean]), where DataType is an Enumeration value specifying the name and type of data and the filter defines the condition on the value.
This way you can specify generic queries for entities, which is reusable for requests to other data storing actors. You could also include a Boolean indicating for each data field whether it has to be set for an entity to be returned in the result. In case you store all those information belonging to one entity (e.g name, age,...) in an Entity object (e.g your persistent actor has some storage for multiple such Entities), you could implement the filtering generically within that Entity class, and ur data providing actor is free of this logic.
I have read that it best practice to use method in REST as an indicator of operation performed on the resource.Lets say i have 5 operation,I am using below resource and methods:
Resource /customer- POST- CreateCustomer
DELETE-delete customer
PUT-update customer
Now I have 2 more operations of query : findCustomer and queryCustomer.
I can use GET method for one of them only.What is the best practice to handle such scenario because passing an explicit HTTP header or extra query string for identifying 1 exceptional opertaion doesnt seem like a good alternative !
I have 2 more operations of query: findCustomer and queryCustomer. I can use GET method for one of them only.
The GET method is suitable for both operations, however you must use different URIs.
Use the following to retrieve a representation of a collection of customers (the operation you define as query):
GET /customers
The collections can be filtered with query parameters.
And use the following to retrieve a representation of a single customer (the operation you define as find):
GET /customers/{id}
{id} is a unique identifier for your customer.
Related: See this answer for some insights on which status code can be returned in each situation.
We have a resource collection for products: /products.
We want to filter this collection to only return the members which have one of a list of specific class id's. For example:
GET /products?classes=100,101,102
This should return a collection of product members which have any of the classes listed.
The issue we have, is that we're working with thousands of products and classes, so the class list of id's could be thousands long - too long for a query string.
I'm keen to stick to RESTful principles whenever we can, so I like the fact that the resource /products?classes=100,101,102 when called with GET returns a filtered products collection.
Obviously, we could include the id's list in the body in JSON format, but that would mean that the call GET /products won't return a representation of the state of the resource (the resource being the URL), because the body is being used to provide filter options.
What's the best way to request a collection which is filtered, but the filter options are too long to use the query string..?
Interesting comment from #C. Smith who suggests making a POST call using a X-HTTP-Method-Override header set to GET and passing the id's in the body. This would work.
After thinking about it we're probably going to limit the number of class id's allowed in the query string, and suggest making multiple calls, breaking up the id's list into say, groups of 200. Submitting more than 200 would return an error.
GET /products?classes=1004,2342,8753... (limited to 200 id's)
GET /products?classes=2326,3343,6981... (limited to 200 id's)
Then the results can easily be stitched together after.
This method would let you use 5,000 id's for example, by doing 25 calls, which while not ideal, is ok for our use case.
I'm currently working on something that involves iterating through a Sales Order and Sales Order Products via a trigger on the Sales Order object. I've created an Apex class that is called from the Sales Order after update trigger. The trigger passes a string (Sales Order Id) to the static method of the class. This future call method queries for Sales Order Products that belong to the Sales Order id, and makes a web service call for each item in the collection. This all works great, however I would like for this process to be more robust and handle errors more intelligently. What I would like to be able to do is abort the whole process when the method encounters something it doesn't like, let's say it identifies a product in the order it doesn't like as an example. The only process I've found that can handle aborting is via the Queueable Interface, and calling the class via System.enqueueJob(). This however doesn't help me as I cannot for the life of me figure out a way to pass any parameters to this class when System.enqueueJob() is invoked, since the class methods are static and the interface forces the process to run from the execute() method, which only takes a Context parameter. Am I going down the wrong road with this? The only other possibility I was thinking of was to just create methods for all of the subprocesses in my class and return from those if they encounter any errors and set a bool flag that can be used to skip processes afterward in the class. Sorry if this doesn't make sense, if so let me know and I'll try to provide more information.
You can pass parameters to a Queueable job in the constructor. i.e.:
System.enqueueJob(new myQueueableClass(salesOrderId));
You need to add a constructor in your Queueable class that will accept the Sales Order Id and store it in a private variable also declared inside the Queueable class, which then can be accessed by the execute() method.
Some days ago when I made a query to Orion context broker with regular expressions, the response included all the entities that match that regular expression, now only retrieve the data of the older entities and if i want to access to the most recent entities, I need to make another request with a more specific regular expression.
The problem is that now I need to make two different querys with differents regular expression to retrieve the old and new entities when a week ago I only had to make one with the most generic regular expression.
Imagine that the structure of the id of my entities are:
dev:name_proyect:name_object:name_service
Some days ago I only need this generic expression to retrieve all the data:
dev:name_proyect:.*
Now I need two queryes to obtain the same result:
dev:name_proyect:.* -> the response only include old entities
dev:name_proyect:name_object:.* ->the response retrieve only the new data
So, the use of regular expression have changed in Orion CB? I need to do something else now to retrieve all the data with only one query with the most generic regular expression?
The instance of Orion that I am using is:
http://orion.lab.fi-ware.eu:1026
Note that since 0.14.0, Orion implements pagination, which details are described in the corresponding section in the user manual.
There is a default limit of 20 in the number of entities retrieved by queryContext (and related convenience operations). If you want to increase that limit, use the limit URI parameter, e.g.
POST http://orion.lab.fi-ware.eu:1026/ngsi10/queryContext?limit=200
The absolute maximum limit is 1,000. If the query covers more than 1,000 result, the client have to retrieve the data in several chainned requests, using the offset parameters (see details in the above reference).
You can get a hint on how many entities are covered by the query using the details parameter, e.g:
POST http://orion.lab.fi-ware.eu:1026/ngsi10/queryContext?details=on
...
"errorCode": {
"code": "200",
"details": "Count: 2342",
"reasonPhrase": "OK"
}