I'm using CouchDB and I have a situation where there are a bunch of documents keyed on user ids. I would like to be able to send a single query to update a particular field in all these documents. For example when a notification comes in, I'd like each user document to be updated with it by passing in the list of users to whom the notification applies and the notification message.
Sadly the _update handlers in CouchDB currently only support a single document at a time, so it's not possible to use an _update handler on multiple documents. For this, you'd need to build a small "proxy," server-side script that would receive the request and send individual _update handler requests one per document. Not ideal, but until there's a patch to allow bulk update handlers to be built, this is the way to go.
I've requested a _bulk_update handler (or similar) be added to a future version of CouchDB...as I'd like the feature as well. :)
https://issues.apache.org/jira/browse/COUCHDB-1303
I'd read _changes (probably apply a filter) and then execute the HTTP queries needed.
Keep in mind that you'll need to fetch the document, before updating it.
Related
I read a lot about each and every function of those mentioned in the title,
But I always have doubt that what is the primary use of all individual functions. Can someone explain to me in detail? Thank you.
What is the use of all GET, PUT, DELETE when anything can be done by POST
This is a pretty important question.
Note that, historically, SOAP essentially did everything by POST; effectively reducing HTTP from an application protocol to a transport protocol.
The big advantage of GET/PUT/DELETE is that the additional semantics that they promise (meaning, the semantics that are part of the uniform interface agreed to by all resources) allow us to build general purpose components that can do interesting things with the meta data alone, without needing to understand anything specific about the body of the message.
The most important of these is GET, which promises that the action of the request is safe. What this means is that, for any resource in the world, we can just try a GET request to "see what happens".
In other words, because GET is safe, we can have web crawlers, and automated document indexing, and eventually Google.
(Another example - today, I can send you a bare URI, like https://www.google.com and it "just works" because GET is understood uniformly, and does not require that we share any further details about a payload or metadata.)
Similarly, PUT and DELETE have additional semantic constraints that allow general purpose components to do interesting things like automatically retry lost requests when the network is unreliable.
POST, however, is effectively unconstrained, and this greatly restricts the actions of general purpose components.
That doesn't mean that POST is the wrong choice; if the semantics of a request aren't worth standardizing, then POST is fine.
In API perspective,
GET - It is to retrieve record/data from a source. API would need no data from client/UI to retrieve all records , or would need query param / path param to filter records based on what is required - either record with a particular ID or other properties.
POST - it is to store a new record at a source . API would get that record from client/UI through request body and store it.
PUT - it is to update an existing record at a source . API would receive updated record along with Id and update it with existing record whose id match with one passed from UI.
DELETE - it is to delete a record present in source. UI would send nothing to delete whole all records at source or send id to remove a particular record.
Source refers to any database.
I have a doubt. When is a GET request sent. I mean, I have seen a lot of people using if request.method == 'GET', when they render the form for the first time, but when the form is submitted, they do a `POST' request.
While they explicitly mention when defining the form in html that the method will be 'POST', they don't do the same for 'GET' request which is made when an empty form is requested.
How does django know it's a GET request?
And, why is it done so?
Thanks,
I'm not an expert but I think Django "knows" this because like all things on the Internet it uses the HTTP protocol. There are several HTTP methods. If not specified the default method will always be GET
GET
A GET is usually used to retrieve information. Typically a GET function has no side-effects (this means that data in the database is not changed, that no files in the filesystem are modified, etc.).
Strictly speaking this is not always true, since some webservers log requests (themselves) and thus add an entry to the database that a specific user visited a specific page at a specific timestamp, etc.
A typical GET request is idempotent. This means that there is no difference between doing a query one time, or multiple times (two times, three times, five times, thousand times).
GET queries are therefore typically used to provide static content, as well as pages that contain data about one or more entries, search queries, etc.
POST
POST on the other hand typically ships with data (in the POST parameters), and usually the idea is that something is done with this data that creates a change in the persistent structures of the webserver. For example creating a new entry in some table, or updating the table with the values that are provided. Since these operations are not always idempotent, it can be dangerous if the user refreshes the page in the browser (since that could for example create two orders, instead of the single order the user actually wanted to create).
Therefore in Django a POST request will typically result in some changes to the database, and a redirect as result. This means that the user will typically obtain a new address, and perform a GET request on that page (and that GET is idempotent, hence it will not construct a new order).
PUT, PATCH and DELETE
Besides the popular GET and POST, there are other typical requests a client can make to a webserver. For example PUT, PATCH and DELETE.
PUT
PUT is the twin of a POST request. The main difference is that the URI it hits, specifies what entry to construct or update. PUT is usually an idempotent operation.
This means that if we would for example perform a POST server.com/blog/create to create a blog, PUT will typically look like PUT server.com/blog/123/. So we specify the id in advance. In case the object does not yet exists, a webserver will typically construct one. In case the entity already exists, a new entity will typically be constructed for that URI. So performing the same PUT operation twice, should have no effect.
Note that in case of a PUT request, typically one should specify all fields. The fields that are not specified will typically be filled in with default values (in case such values exist). We thus do not really "update" the entity: we destroy the old entity and create a new one in case that entity already exists.
PATCH
PATCH is a variant of PUT that updates the entity, instead of creating a new one. The fields that are thus missing in a PATCH request, typically remain the same as the values in the "old" entity so to speak.
DELETE
Like the name already suggests, if we perform a DELETE server.com/blog/123/ request, then we will typically remove the corresponding element.
Some servers do not immediately remove the corresponding element. You can see it as scheduling the object for deletion, so sometimes the object is later removed. The DELETE request, thus typically means that you signal the server to eventually remove the entity.
Actually Django is based on HTTP responses-requests. HTTP is fully textuall. So Django parses each request and finds in its header information about what kind of request is it. I may be mistaken in details, but as I understand when server receives request - Django creates it's object request, which contains all the data from HTTP. And then you decide if you need a specific action on GET or POST and you check the type of request with request.method.
P.S. And yes, by default each request is GET.
This is more of a question on design approach. I have an application which has the following details:
UI in Angular
UI uses an api which is in Node/Express
Database is just a JSON file for now.
I want to move to mongoDb from the JSON file. What I'd like is, whenever anyone uses the UI to make changes to the database, I'd like to review the changes before they are updated in the database. what is the best way to achieve this?
This was easier for me with the JSON file because I was creating a pull request on git where I would review all the changes and then update.
Things that I have thought:
Let the UI write to a separate clone collection(table) and then review them and update the main collection accordingly. Not sure if this is the right way to do it.
Are you yourself wanting to review changes, or wanting an end user to review before saving? If it's you, you have a few options:
You can create a mongodb collection of pending objects that will get moved to a different collection once they're approved. This is OK, but not great because you'll end up shuttling objects around and it's probably more reasonable to use a flag to do aggregate grouping instead of collection-based delineation
You can simply use a property on an object as a flag and send objects that are pending review to your db with that flag enabled (using some property like true, 1, or another way of saying "this is true/on/enabled etc.")
If you want an end-user to be able to save, you can use mongoose hooks/middleware to fire off validators or whatever you want and return a response with meaningful data back to your angular UI. From there, you can have a user 'review' what they're saving. This doesn't persist or get saved, it's only saved once they send everything back up again (if that's how you choose to build the save process).
Is there common design pattern for dispatching deleted objects to the requestor (client of the API)?
Challenges we are having:
When object is deleted on the API completely, client will not know
that object is gone and will keep it locally (as API only shows objects changed after the certain date)
If we enable object's property to show that is deleted (ex. "deleted = TRUE") then
eventually number of objects in the API grows and slows down the transfer rate.
Another option we looking into is to have separate Endpoints on the API to show list of deleted objects only (is this the pattern that anyone uses?).
I'm looking for most "RESTful way" to delete local objects.
The way I handle it is a variation on your #1: each item has a last updated field in the database, and if something is deleted, I make an entry in another table of deleted items, and it's updated value is when it was deleted.
The client makes a request asking for "changes since X" which is their own locally stored last updated value...it returns new data, and an array of deleted items. Then on the client I purge those values
Stale data is always a problem with client/server applications. If clients loads some data, then some object is deleted on the server, and then client sends a DELETE request, the RESTFul thing to do would be to return a 404, which indicated "not found". If the client knows that if it sends a DELETE, and gets a 404, the resource was deleting from underneath...
What if you think of your resource not as a list, but rather as a changeset?
Eg. changesets what you have in git or SVN.
This way, there's always a "head" version, and the client always has some version, and the resource is the change between client's last and head.
That way you can apply whatever you've learned by examining/using version control systems.
If you need anything more complex, the science behind is called Operational Transformation (OT) - http://en.wikipedia.org/wiki/Operational_transformation
I am creating a dashboard application in which i show information about the servers. I have a Servlet called "poller.java" that will collect information from the servers and send it back to a client.jsp file. In the client.jsp , i make AJAX calls every 2 minutes to call the poller.java servlet in order to get information about the servers.
The client.jsp file shows information in the form of a table like
server1 info
server 2 info
Now, i want to add one more functionality. when the user clicks on the server1, I should show a separate page (call it server1.jsp) containing the time stamps in which the AJAX call was made by calling.jsp and the server information that was retrieved. This information is available in my calling.jsp page. But, how do i show it in the next page.
Initially, i thought of writing to a file and then retrieving it in my server1.jsp file. But, I dont think it is a good approach. I am sure i am missing a much simpler way to do this. Can someone help me ?
You should name your servlet Poller.java not poller.java. Classes should always start with an uppercase. You can implement your servlet to forward to a different page for example if sombody clicks to server1 then the servlet will forward to server1.jsp. Have a look at RequestDispatcher for this. Passing information between request's should be done by request attributes. if you need to retain the information over several request you could think about using session.
In the .NET world, we use SessionState to maintain data that must persist between requests. Surely there's something similar for JSP? (The session object, perhaps.)
If you can't use session state in a servelet, you're going to have to fall back on a physical backing store. I'd use a database, or a known standard file format (like XML). Avoid home-brew file formats that require you to write your own parser.