A possible solution that pops up thinking about documents that can grow to big is to have them divided in logical pieces. A too big document is not easy to manage in a form anyway, so the division seems to be an adequate approach even from the application usability point of view.
Any other solutions? On Thu, Jul 9, 2009 at 6:01 PM, Ross Bates<[email protected]> wrote: > You have to repost the updated document in it's entirety anytime you update. > > I agree with you, it would be nice to be able to post incremental changes to > a document based on the combination of doc_.id and key but it's not there > today. The problem as I see it is that couchdb is an append only datastore, > to achieve incremental updates the operation would involve couchdb copying > the previous revision, parsing the update, scanning the document, replacing > the key/values. > > I will defer to any of the couch developers as to whether or not it's even > possible given how the engine is written. > > > > On Thu, Jul 9, 2009 at 6:04 AM, Vlad GURDIGA <[email protected]> wrote: > >> Thank you for your response! >> >> On Wed, Jul 8, 2009 at 5:02 PM, Ross Bates<[email protected]> wrote: >> > This depends on how you design your database. >> > >> > What the documentation is saying there is that you can bulk insert docs >> > straight up without any additional information. >> > >> > On the other hand to update documents you would need to know their id's >> > ahead of time. >> > >> > In the situation you describe where you are updating based on an >> attribute >> > it's likely that even if you were using a naming convention for the >> doc._id, >> > it wouldn't be readily available before updating. >> > >> > For situations like this I would create a view that emits category_id, >> > select from the view, turn it into an object client side, update, then >> > repost. >> >> OK. That thing with the view sounds feasible. >> The next question that pops up is: would it be possible to update just >> a single property of a document without having to get and resend all >> of the document's content? That would be nice, because I'm afraid in >> case of multiple documents (it's bulk update we're coming from) the >> request could get heavy weight. >> >> > >> > I know that sounds crazy when you compare it to SQL, but from my >> experience >> > you'll be much better off if you don't draw comparisons to SQL. You have >> to >> > take a completely different mindset to application design. Things that >> may >> > seem counter intuitive at first prove to be elegent in their simplicity >> in >> > the long run. >> >> I'm on my way. :) >> Thank you! >> >> > >> > -Ross >> > >> > >> > On Wed, Jul 8, 2009 at 1:55 AM, Vlad GURDIGA <[email protected]> wrote: >> > >> >> Hello! >> >> >> >> The CouchDB wiki says "CouchDB provides a bulk insert/update feature. >> >> To use this, you make a POST request to the URI /{dbname}/_bulk_docs, >> >> with the request body being a JSON document containing a list of new >> >> documents to be inserted or updated." So, as far as I can understand, >> >> this means that I first need to read the documents in order to bulk >> >> update them. I wish I am mistaken. >> >> >> >> If I need to move products from one category to another, I would that >> >> in SQL with a statement like this: >> >> >> >> UPDATE products SET category_id=1 WHERE category_id=2 >> >> >> >> Is there any way to do that in CouchDB? >> >> >> >> >> >> Thank you! >> >> >> > >> >
