On Apr 19, 2010, at 6:29 PM, Michael Genereux wrote: > The more I think about what I was suggesting, the less I think it > needs to be transactional. If I really cared, for example in the > update version, I would include a "pricing version" field that the > document's price has been increased to the new price and watch that > pricing version if I ran the update again. > > I was really thinking of an easy way to create a bulk insert from a > view. The "CouchDB way" is "it's not transactional across documents." > This is fine with me and an understanding of this should be a > requirement of switching to CouchDB. If someone doesn't get this, my > suggested feature is not the biggest of their problems if switching > from transactional SQL. My workaround for this is currently looking > like a Ruby library that calls a view with all the logic love in > Javascript, tweaks the JSON into a bulk insert, and shoves the thing > back in. (Batch processingTM coming soon.) This is just an > inefficient way to do it. > > As far as compaction, I don't want to sit around waiting for a > compaction on a massive database that is only modifying 5% of its > records. >
If you go back an take a look at Mikeal's node.js _changes handler, you'll see that it exactly what you want (minus the shipping as part of CouchDB part). The only thing that could be better is script that queries a view and works to make it empty (and that is only more efficient if your view already exists - otherwise you have to scan the entire DB to build the view, and if it's a one-time thing, you'd be better of using a filtered _changes query and avoid building a throwaway index. Chris > Loving the feedback BTW! Thank you everyone! > > On Mon, Apr 19, 2010 at 12:49 PM, Randall Leeds <[email protected]> > wrote: >> Ad-hoc db-wide transformations suddenly strike me as a generic form of the >> compactor. The compactor is an identity update function. It achieves a full >> scan of the db by putting results in a new .couch file. It runs until it has >> caught up to the tail of the current file (using a changes listener) and >> then swaps the files. I believe a good patch here is one that creates a code >> path the compactor can share. >> >> The side bonus is that this implementation is transactional. >> >> On Apr 19, 2010 2:51 PM, "Martin Murphy" <[email protected]> >> wrote: >> >> I agree. Some format of bulk changes needs to be integrated into futon >> before the masses will adopt. >> >> On Mon, Apr 19, 2010 at 1:21 PM, Michael Genereux <[email protected]>wrote: >> >>> Thanks! Okay, I need to reread "_changes" and the "all_or_nothing" on >>> the bulk_api. Also "Document Update Handlers" was way too complicated >>> and wanted a record id for what I was looking to do. I have a CouchDB >>> database holding a log and I want to chuck old data easily. Losing >>> quick manipulation when switching to CouchDB seems like a barrier of >>> entry. I don't know of any situation where I haven't used SQL >>> (database), sed (ascii document), or other ad hoc concepts to >>> manipulate records/files/documents. >>> >>> Thanks for the feedback and it was expedient so thanks for that too. >> >>> >>> On Mon, Apr 19, 2010 at 9:45 AM, J Chris Anderson <[email protected]> >>> wrote: >>>> >>>> On Apr 18... >> -- >> Martin Murphy >> Whiteboard-it >> (205) 910-0720 >>
