How does one handle the resource_exists callback in cowboy? After all, to find out whether resource exists - I must query (e.g. database) for resource. But then during the AcceptResource callback (e.g. to_html) I must query for the resource again. Is there any way to prevent this double querying?
Is there any way to preserve that resource for the AcceptResource callback, so that I don't have to pull it form database again?
Reading the cowboy docs, there is flowchart of how a rest request is handled.
In it, the callback resource_exists is called first.
In resource_exists you can add the result of the database query to the State variable that resource_exists returns.
The state is passed as input to the AcceptResource callback where you can use the cached value.
Related
I have an API code, which loads a data necessary for my application.
It's as simple as:
- (void) getDataForKey:(NSString*) key onSuccess:(id (^)())completionBlock
I cache data returned from server, so next calls of that functions should not do network request, until there is some data missing for given key, then I need to load it again from server side.
Everything was okey as long as I had one request per screen, but right now I have a case where I need to do that for every cell on one screen.
Problem is my caching doesn't work because before the response comes in from the first one, 5-6 more are created at the same time.
What could be a solution here to not create multiple network request and make other calls waiting for the first one ?
You can try to make a RequestManager class. Use dictionary to cache the requesting request.
If the next request is the same type as first one, don't make a new request but return the first one. If you choose this solution, you need to manager a completionBlock list then you will be able to send result to all requesters.
If the next request is the same type as first one, waiting in another thread until the first one done. Then make a new request, you API will read cache automatically. Your must make sure your codes are thread-safe.
Or you can use operation queues to do this. Some documents:
Apple: Operation Queues
Soheil Azarpour: How To Use NSOperations and NSOperationQueues
May be there will be so many time consuming solutions for this. I have a trick. Create a BOOL in AppDelegate, its default is FALSE. When you receive first response, then set it TRUE. So when you go to other screen and before making request just check value of your BOOL variable in if condition. If its TRUE means response received so go for it otherwise in else don't do anything.
According to the document on command objects and data binding. Once you read the params object, that object can never be reused again.
From the documentation:
Binding The Request Body To Command Objects
http://grails.org/doc/2.3.x/guide/theWebLayer.html#commandObjects
Note that the body of the request is being parsed to make that work. Any attempt to read the body of the request after that will fail since the corresponding input stream will be empty. The controller action can either use a command object or it can parse the body of the request on its own (either directly, or by referring to something like request.JSON), but cannot do both.
I'm trying to view the parameters within a filter (which is hit before the controller is requested). Would logging the parameters to a log cause the controller to get a null param object? From the documentation that looks to be the case. However, how can I get access to the params without wiping them out in the filter?
Once you read the params object, that object can never be reused
again.
That is not correct. You can read request parameters over and over again. What cannot be read over and over again is the body of the request. The body and the request parameters are 2 different things.
Similar to the iPhone Facebook app search function, I am implementing search as you type functionality into my application although I have a problem when decoding the data into JSON format.
Basically what happens is because some searches take longer than others, they return at different intervals and this causes some small visual issues when the data is presenting on the screen.
I have set an NSLOG after each decode using NSJSONSerialization for the keyword 'industry'
2013-04-09 23:38:18.941 Project Name [42836:1d03] http://fooWebAddress/json/?method=search&limit=10&q=indus
2013-04-09 23:38:19.776 Project Name [42836:3e07] http://fooWebAddress/json/?method=search&limit=10&q=indu
2013-04-09 23:38:20.352 Project Name [42836:8803] http://fooWebAddress/json/?method=search&limit=10&q=indust
2013-04-09 23:38:21.814 Project Name [42836:4e03] http://fooWebAddress/json/?method=search&limit=10&q=industr
2013-04-09 23:38:23.434 Project Name [42836:8803] http://fooWebAddress/json/?method=search&limit=10&q=ind
2013-04-09 23:38:24.070 Project Name [42836:7503] http://fooWebAddress/json/?method=search&limit=10&q=industry
As you can see it is all out of order.
Does anyone have any way of stopping NSJSONSerialization for the previous connection.
Or possibly any other way to go about this problem?
Steps up to NSJSONSerialization...
NSURLRequest (initwithURL)
NSOperationQueue
NSURLConnection (asynchronous)
NSJSONSerialization
Thanks in advance.
When the user starts typing more text, you could cancel your previous connections and ignore any further delegate callbacks you receive from them. Then make the new request for the current text.
You can do this by maintaining some sort of lastRequest or lastOperation reference. When the user starts typing, call [self.lastRequestOrOperation cancel] and ignore any further notifications from that request with a check like if (request != self.lastRequest) { return; } in whatever callbacks you have.
However this has the problem that if the user keeps typing for a while you are constantly cancelling requests and they may not see any results until they have stopped typing.
A better solution would be to add sequencing so that each request is associated with an increasing sequence ID. You then only parse the result and update the UI when the sequence of the response is higher than the last one you received. If you receive any out-of-band responses from earlier, you just ignore them.
This is a much more complex issue than just being able to cancel the NSJSONSerialization. My suggestion is to use NSFetchedResultsController to populate your table view that shows the search results. Use the search term as one of the predicate variable in the NSFetchRequest attached to NSFetchedResultsController. And then, when you parse the results using NSJSONSerialization, store the results with the search term associated with that request. As soon as the search term changed (which you can detect when the user types more characters), re-create the NSFetchedResultsController and reload your table view. In addition, you can also try to cancel the call to parse the previous results if you launched it using performSelector:withObject:afterDelay. Beware that this cannot be always relied upon as the call may have been initiated by the time you are trying to cancel.
Kinda basic, but you could always maintain an nsdictionary of sub-classed NSURLRequests (sub-classed to provide a tag).
Start request - add request to dicationary with tag = array.count - 1, with key matching tag
Connection returns - is the request the most recent request, if so, parse json
Parse JSON - is the request the most recent request, if so, show results, if not, only display if there are no previous results displayed
Request handling - remove key from dictionary
most recent request = does the dictionary contain an object with a higher key value
Currently what you are doing is, you type each character and calling web-service. Why to call web-service for each letter you type. If user is type continuously, then it will increase the load, so call the web-service only when user stops for a particular interval of time. and then pass that string to call web-service or what ever method you are calling.
[NSObject cancelPerformSelectorsWithTarget:self]; // This will cancel your all req which is going to make when user typing without stopping
[self performSelector:#selector(sendSearchRequest) withObject:searchText afterDelay:0.1f]; // This will pass the string to call a web-service method, on which user hold for some time.
I found the "OnQueryStatement" method :
procedure TkbmMWQueryService2.kbmMWQueryServiceQueryStatement(Sender: TObject;
Place: TkbmMWQueryOperationType; var NamedQueryName, Statement: string);
begin
Form1.Memo1.Lines.Add(Statement);//show the query statement
end;
this method can get the client-side query statement,but all the client-side query trigger this event twince!(like the screenshot)!Why? How can i get the client-siade query statement correctly?
thanks in advance! :)
Its called twice on the server (in fact can be called 3 times for the same query on the server in the most far out situation).
Check the Place argument for the situation that its called in.
It can be
mwqotDefinition,mwqotQuery,mwqotExecute,mwqotResolve,mwqotMoreData,mwqotMetaData
The reason its being called multiple times when opening the query, is that the dataset first likes to get the definition (which fields and parameters will this query result in), and then the data itself.
Both the server and the client default operates like that. Hence opening a query on the client result the client in asking the server about definitions, then the client asks for the data, and that on the server may result in the server itself asking for definitions and then the data. Remember the server is stateless and default doesnt know anything about previous calls to it.
There are many ways to optimize this:
Enable caching for metadata (definitions). That will result in the cache results being used instead of the server asking the database for the definitions, and enabling the cache on the client too, results in the client not having to ask the server for definitions except first time.
Setup the AutoFieldDefs property on the query to mwafoWithData. Then the data will actually be returned at the same time as the definitions, and the 2.nd data fetch call will be skipped.
Let's say I have an AddProductToCartTask with a method Execute().
Now, the task is being called from a Controller. In the Execute method , there
is a check that if not met - the action is not performed.
Let's say the message returned would be: "You do not have enough bonus to buy
this product".
I thought about launching an event when the domain validation fails - but that would mean that in the Controller I have to have all kinds of class variables that need checking in the action (to determine if I need to set an error message, or i need to redirect .. etc)
Instead of this I could have a method on the task : GetErrorMessages(). If empty
return the JSON object if not empty return the Message. Or the method could return an enum that would tell if i need to redirect or set a message or return the object ....
I'm not sure which road to take. Any input would be appreciated. How do you bubble up messages from your domain layer ?
Edit: this is mainly in an AJAX context. Even though I'm not sure it matters as it's an action that it's getting called from somewhere .
I might be misunderstanding your request, but it seems to me like you want a central messages functionality, rather than something specific to the task object. If you leave it in your task, then the task must be kept in scope and "alive" until the AJAX request.
I do something similar, though directly from the Controller.
I have a static class called Messages. It has AddMessage(), GetLastMessage(), and GetAllMessages() methods. Each one, when first called, will check the user's session variable and, if nothing is found, creates and saves a Queue<string>() object. The methods are basically just an interface to the Queue. The Queue is nice because it handles push/pop which automatically removed "viewed" messages.
My controller does:
Messages.AddMessage("Product Saved");
You could potentially do:
Messages.AddMessage(task...GetErrorMessages());
Then, from my View, I have an html helper that checks how many error messages there are and, if any, creates a <ul> with each message as a <li>.
You could just as easily have a GetMessages() controller that returns any messages as a JSON object.
James