Yes, that's what I mean. The word "transactional" means far more than "sent in the same HTTP request". :)
B. On 10 June 2011 14:16, Sean Copenhaver <[email protected]> wrote: > Ah I think I see what you mean: > > "*all-or-nothing* - To use this mode, include "all_or_nothing":true as part > of the request. In the case of a power failure, when the database restarts > either all the changes will have been saved or none of them. However, it > does not do conflict checking, so the documents will be committed even if > this creates conflicts" > > So even though you "transactional" committed multiple documents, when you > retrieved them you won't always get what you committed. > > On Fri, Jun 10, 2011 at 8:47 AM, Robert Newson <[email protected]>wrote: > >> The bulk documents API is not transactional in any useful sense. >> >> On 10 June 2011 13:42, Sean Copenhaver <[email protected]> wrote: >> > It sounds like you are trying to combine things into a single document. >> What >> > were your concerns that you would want to put all manufacturers in a >> single >> > document or all log entries for example? That is instead of in a view >> query >> > result? >> > >> > I don't think there would be an issue with having everything as a >> separate >> > document. There are ways to pull back related documents in one query that >> > would resolve concerns of having to do many hits. As an example, you >> could >> > create a view to be able to pull back the device, user, and profile in >> one >> > query. >> > >> > The wiki has some information on managing relationships: >> > http://wiki.apache.org/couchdb/EntityRelationship >> > >> > On the flip side there are ways to perform CRUD operations on multiple >> > documents at once, including transactional (although with multiple dbs >> you >> > can run into inconsistencies as the transaction won't hold up across >> > replication): >> > http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API >> > >> > >> > 2011/6/10 Javier Rodríguez Escolar <[email protected]> >> > >> >> Hello, I'm a CouchDB newbie trying to migrate an existing application >> from >> >> SQL to NoSQL. I have designed different approaches to model the CouchDB >> >> documents and I have been leafing through a couple of books [1],[2] in >> >> order >> >> to figure out the possible problems each approach might cause, but I >> still >> >> have some doubts. Basically the data model of my application domain has >> the >> >> following scheme: >> >> >> >> *Data model overview* >> >> >> >> - Mobile manufacturers (in the order of 60). Each manufacturer has >> >> different models: >> >> - Mobile models (in the order of 2000 per manufactorer) >> >> - Errors. Each manufacturer has a set of types of errors (in the order >> of >> >> 1000 per manufacturer) >> >> - User >> >> - Mobile device >> >> - Profile. Identified by a User and a MobileDevice >> >> - DebugLog. Each debug log takes just 10 words and one DebugLog per >> >> second is sent to the server. >> >> - ErrorLog. Each error log takes just 10 words and they are generated >> >> once in a while. >> >> - So, my main doubts are listed below: >> >> >> >> >> >> *Doubt 1 (manufacturers and models)* >> >> >> >> - Option 1 >> >> - One document for all the manufacturers: "Manufacturers". It just >> >> includes a list of manufacturers, each of them has an identifier. >> >> - One document per model: "ModelX". Each model includes a reference >> to >> >> its manufacturer. >> >> - Option 2 >> >> - One document for all the manufacturers: "Manufacturers". It >> includes >> >> a list of manufacturers. Each manufacturer points to a list of >> models. >> >> - One document per manufacturer: "ListOfModels". It includes all >> the >> >> models for a given manufacturer. >> >> >> >> *Doubt 2 (logs)* >> >> >> >> - Option 1 >> >> - One document per DebugLog: "DebugLogX". >> >> - Option 2 >> >> - One document per application life cycle: >> >> "DebugLogsDuringApplicationLifeCycleX". It includes all the debug >> logs >> >> created by the application during its life cycle. An application >> >> life cycle >> >> might takes from just a few seconds to some hours. >> >> >> >> *Doubt 3 (user, mobile and profile)* >> >> >> >> - Option 1 >> >> - One document per profile: "ProfileX". It includes information >> about >> >> the mobile device and the user. >> >> - Option 2 >> >> - One document per user: "UserX" >> >> - One document per device: "DeviceX" >> >> - One document for all the profiles: "Profiles". It contains a list >> of >> >> profiles, each one pointing to its associated user and device. >> >> >> >> >> >> *Doubt 4 (manufacturer errors)* >> >> >> >> - Option 1 >> >> - One document for all the errors. Each error is associated to its >> >> manufacturer. >> >> - Option 2 >> >> - One document per manufacturer: "ManufacturerXErrors". >> >> >> >> >> >> I would appreciate any piece of advice. >> >> >> >> Thanks in advance and congrats for your project, >> >> >> >> >> >> [1] >> >> >> >> >> http://www.amazon.com/Beginning-CouchDB-ebook/dp/B003U890N2/ref=sr_1_10?ie=UTF8&qid=1307691243&sr=8-10 >> >> [2] >> >> >> >> >> http://www.amazon.com/CouchDB-Definitive-Guide-Animal-ebook/dp/B0043D2E9U/ref=sr_1_3?ie=UTF8&qid=1307691243&sr=8-3 >> >> >> > >> > >> > >> > -- >> > “The limits of language are the limits of one's world. “ -Ludwig von >> > Wittgenstein >> > >> > > > > -- > “The limits of language are the limits of one's world. “ -Ludwig von > Wittgenstein >
