From couchdb-user-returnelliottmatthew@example.net Mon Dec 01 07:39:45 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 89962 invoked from network); 1 Dec 2008 07:39:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Dec 2008 07:39:45 -0000 Received: (qmail 36349 invoked by uid 500); 1 Dec 2008 07:39:55 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 36315 invoked by uid 500); 1 Dec 2008 07:39:55 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 36304 invoked by uid 99); 1 Dec 2008 07:39:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 30 Nov 2008 23:39:55 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elliottmatthew@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO unicron.groovie.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 07:38:26 +0000 Received: from c-24-130-69-255.hsd1.ca.comcast.net ([83.161.120.155] helo=Shaggy.home.groovie.org) by unicron.groovie.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <elliottmatthew@example.net>) id 1L73N7-0008Q9-UG for elliottmatthew@example.net; Sun, 30 Nov 2008 23:39:11 -0800 Message-Id: <elliottmatthew@example.net> From: Ben Bangert <elliottmatthew@example.net> To: elliottmatthew@example.net Content-Type: multipart/signed; boundary=Apple-Mail-4-701839012; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Ordering by values calculated by a map/reduce Date: Sun, 30 Nov 2008 23:39:01 -0800 X-Mailer: Apple Mail (2.929.2) X-Spam-Score: -4.0 (----) X-Spam-Report: Spam detection software, running on the system "unicron.groovie.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I want to solve what I thought was a fairly simple problem, though unfortunately it seems to be rather tricky. I asked on the IRC channel, and got some good input, but neither really seemed like a very good solution. [...] Content analysis details: (-4.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: From: address is in the auto white-list X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-4-701839012 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I want to solve what I thought was a fairly simple problem, though unfortunately it seems to be rather tricky. I asked on the IRC channel, and got some good input, but neither really seemed like a very good solution. The problem: I want to allow users to rate things. They do this very very frequently, so I can't store it in the actual document being rated, so I have Rating documents. It's easy enough to write a map/reduce that gives me the computed average rating for a given document, however, it seems to be impossible to get a listing of the highest rated documents, as I can only get the computed rating for a document one at a time. The possible solutions: - Buffer rating additions, then at a later time, run through them and calculate the new average rating, store it in the document as computed_rating, so I can order on that in the key - Cron a job that goes in and looks for new rating every 5 mins or whatever, and then does the same as the previous solution by storing it in a computed_rating field I'm not a fan of either of these, because #1 means if my webapp hiccups, I lose ratings, and #2 is just a pain to keep sweeping the db for new Rating documents then going through updating all the documents. Is there really no other solutions that don't require me to store the computed rating in the doc itself? There's no way I can perhaps order on the value from the map/reduce, rather than only being able to order on the key? Thanks, Ben --Apple-Mail-4-701839012 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGfTCCAzYw ggKfoAMCAQICEClzcfApE1Xl0tE8fQf6InIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUyMzIyMDUzNVoXDTA5MDUyMzIyMDUz NVowZjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmJh bmdlcnRAZ3Jvb3ZpZS5vcmcxHjAcBgkqhkiG9w0BCQEWD2JlbkBncm9vdmllLm9yZzCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAxyJSHPp0a6b6jg37ULZHv6Vh+ZthZh0LIACrEkeDU KT2Gop2+h7wuoZNRSOLGSijSuMmYL9whUZmDLefzwkU8/yL7Ya6dh+QE3L0TM2nGqhF1v6/uzQaN cYukSeWkRMx2QrRGpu5npDWUsMN8vKMziDlVpjpQKDfnupVFa34vhWpavJliaDh4KbPBBfesR3Xg wEdgwOmhfL/lgDNdO8SHtZ3+s/ysf095eM5b2IP+kLyF2t/NOFTA3zIWbjOAIGyyxyt7J2x1oEAT 1VlATLQ0+DQhh4UZS/PIJpJsOGxttjfqKTTbXivBDDUEq843wz4L0X5YZlv4ky8vAj1bolsCAwEA AaNlMGMwDgYDVR0PAQH/BAQDAgP4MBEGCWCGSAGG+EIBAQQEAwIFIDAwBgNVHREEKTAngRRiYmFu Z2VydEBncm9vdmllLm9yZ4EPYmVuQGdyb292aWUub3JnMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADgYEAArp/WahHEAzWmCz+VUX1PmjwbxRTy9T0z6Z52EUbvrU9mnOPHTC0hgHXYzMtEKW5 8apV7CnoHyFucbYfqJi+R3xx+4x5M7e+Oj+7JWhxjKH+aXsL1eI1ialOenSDq9VKhyUuF2lCrFIm fTsG+h02NRZyMYQ/OskM0ReNFALAEygwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcN MTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0Ew gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb 8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYD VR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2j ZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4l UJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9d X2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEClzcfApE1Xl0tE8fQf6InIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMjAxMDczOTAyWjAjBgkqhkiG9w0BCQQxFgQUkT5fc2EM UpnjFLfcBzDlRoHphNQwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhApc3HwKRNV5dLRPH0H+iJyMIGHBgsqhkiG9w0BCRACCzF4oHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhApc3HwKRNV5dLRPH0H +iJyMA0GCSqGSIb3DQEBAQUABIIBAAvA05pC2TqYoIVTEiR0wOAhvjbN1aaT+qPX87vtPSCMgoKl P7amRKi0eIjQFoohnlHHWdw9l0e6f8sSa8N/27n7nuYx4lMdG8Q/EQJsepTixhf0CVp/S4C6ma6z 4BrNk5+LZtk2UMZgMKD5/CmY/UAcLUg076IIPHh7gdV8X6n3qXKky/B/GP8j94rTzkjDu1DkqgUo DIso54ToOYE5lY4f+fmxT39G349gIsF646sNTkCzf9oZKoS1e6Fy55l6JKn6Ti2oxMGkQ8hPA5pW 97I8jrNcAtamoT3c3/vGXqfK4qzpRE6prFYj/RihmGISM+L4jeYsY1ekHP5z+ftr8BUAAAAAAAA= --Apple-Mail-4-701839012-- From couchdb-user-returnelliottmatthew@example.net Mon Dec 01 08:02:57 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 98199 invoked from network); 1 Dec 2008 08:02:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Dec 2008 08:02:55 -0000 Received: (qmail 54976 invoked by uid 500); 1 Dec 2008 08:03:06 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 54944 invoked by uid 500); 1 Dec 2008 08:03:06 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 54933 invoked by uid 99); 1 Dec 2008 08:03:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 00:03:05 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elliottmatthew@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO rv-out-0708.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 08:01:37 +0000 Received: by rv-out-0708.google.com with SMTP id k29so2895300rvb.0 for <elliottmatthew@example.net>; Mon, 01 Dec 2008 00:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=F/yTdwACRR/NxoNxR7i2d2sosiuaqguMXFLedRRw0UI=; b=btxObjx3ghpoAvjiYvj62qvkyvYcKyF7kAjPmlbgchoRbJubCiSnyOJNJmCapQJ3PO aLK6Ujr3t0QxV4jyLUN62u+GrjBn0QRtB1BaZi6HZPOudf8ywpMVDqvbnXiEg0lFSJH7 CxvV6cZ3h5Era3rFTL/p2u/6/LisBAXv5wi6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=on0KdyXMg/s5KqD0R6/MIXwfPvLvPWeFFjgYGSS3Vp5EZnd/8TdYIVvOEPtLCwrEw0 7R7Si4sZJWPp3HGLts9Wt7hgKFqrLuYcUEVP1SEp1CyQFFAZ3qeT9Bb4/Dax6QnPOI+q 3aak0KZKjyaauiK5sB5R/GHTxBUbmt1Jj+6/A= Received: by 83.161.120.155 with SMTP id a9mr5109403rvg.64.1228118544420; Mon, 01 Dec 2008 00:02:24 -0800 (PST) Received: from ?83.161.120.155? (ppp121-45-41-103.lns10.adl2.internode.on.net [83.161.120.155]) by mx.google.com with ESMTPS id k37sm11246818rvb.1.283.161.120.155.02.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Dec 2008 00:02:23 -0800 (PST) Message-Id: <elliottmatthew@example.net> From: Antony Blakey <elliottmatthew@example.net> To: elliottmatthew@example.net In-Reply-To: <elliottmatthew@example.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: Ordering by values calculated by a map/reduce Date: Mon, 1 Dec 2008 18:32:19 +1030 References: <elliottmatthew@example.net> X-Mailer: Apple Mail (2.929.2) X-Virus-Checked: Checked by ClamAV on apache.org On 01/12/2008, at 6:09 PM, Ben Bangert wrote: > I want to solve what I thought was a fairly simple problem, though > unfortunately it seems to be rather tricky. I asked on the IRC > channel, and got some good input, but neither really seemed like a > very good solution. > > The problem: > > I want to allow users to rate things. They do this very very > frequently, so I can't store it in the actual document being rated, > so I have Rating documents. It's easy enough to write a map/reduce > that gives me the computed average rating for a given document, > however, it seems to be impossible to get a listing of the highest > rated documents, as I can only get the computed rating for a > document one at a time. > > The possible solutions: > - Buffer rating additions, then at a later time, run through them > and calculate the new average rating, store it in the document as > computed_rating, so I can order on that in the key > - Cron a job that goes in and looks for new rating every 5 mins or > whatever, and then does the same as the previous solution by storing > it in a computed_rating field > > I'm not a fan of either of these, because #1 means if my webapp > hiccups, I lose ratings, and #2 is just a pain to keep sweeping the > db for new Rating documents then going through updating all the > documents. > > Is there really no other solutions that don't require me to store > the computed rating in the doc itself? There's no way I can perhaps > order on the value from the map/reduce, rather than only being able > to order on the key? I use an external query handler to solve problems that don't fit map/ reduce. I've modified Paul Davis's _external handler to pass the current update_seq whenever an external query is made. In the external process (ruby in my case) I maintain a SQLite database that I can use for queries that Couch isn't suited for. Whenever a query comes in, I compare the supplied update_seq with one stored in my sqlite db (of course I cache that in memory as long as the process lives). If the sqlite db is out of date, then I do a _all_docs_by_seq and update sqlite, including the update_seq record, before doing the (SQL) query and responding with a JSON document in the same format as Couch would. I can delete the sqlite db at any time (well, while the process is stopped) because it will get recreated/updated when a query comes in as necessary. This works with replication. This system has the same lazy-update characteristics as Couch views, and has the additional advantage that you can do in-memory caching in the external process which depending on your update frequency, means you rarely hit the db. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 What can be done with fewer [assumptions] is done in vain with more -- William of Ockham (ca. 1285-1349) From couchdb-user-returnelliottmatthew@example.net Mon Dec 01 08:23:24 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 7027 invoked from network); 1 Dec 2008 08:23:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Dec 2008 08:23:24 -0000 Received: (qmail 74193 invoked by uid 500); 1 Dec 2008 08:23:35 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 74144 invoked by uid 500); 1 Dec 2008 08:23:34 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 74133 invoked by uid 99); 1 Dec 2008 08:23:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 00:23:34 -0800 X-ASF-Spam-Status: No, hits=1.8 required=10.0 tests=MIME_QP_LONG_LINE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elliottmatthew@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO fg-out-1718.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 08:22:06 +0000 Received: by fg-out-1718.google.com with SMTP id l26so1765160fgb.26 for <elliottmatthew@example.net>; Mon, 01 Dec 2008 00:22:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:to:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding:content-disposition; bh=bI3euRLm9YtNlZcVkydO7xvYIAgueTKUDd+AYq4grng=; b=pdedt8ZRy7CMMBarVK1nUwj3A9VHrrBr9bNoPkbVc4pZIW7HdpYMrCsxQq2xZKmcqG /vngr0HyHinw7HE3q8qC2oJk9WYYD2I7DuUk86GA/wEZv+ikU4NOoi/deVG+ekiwogJU jkA4RvamBiDows3VdOof1zyNlhSuTzks2tqiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:to:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding:content-disposition; b=uSNeP3PogpjNzmkLEZbk4yL7UxblCurMqDwyGsAX66xe/X3ITSzSVW6uK0m5wtj0MO PEORI8bODfTqOLvUAz6BO94EYzG1KpiG5Li7wBrcU2g5XqJMw908DFInC7duIIPWWZO5 JDZ7Q4rM6w9qkWQMbvcDiN7H5lcVJHF+BfG7Y= Received: by 83.161.120.155 with SMTP id l12mr3863099bkn.26.1228119762661; Mon, 01 Dec 2008 00:22:42 -0800 (PST) Received: from ?83.161.120.155? ([83.161.120.155]) by mx.google.com with ESMTPS id 35sm8633965fkt.34.283.161.120.155.22.40 (version=SSLv3 cipher=RC4-MD5); Mon, 01 Dec 2008 00:22:41 -0800 (PST) Date: Mon, 01 Dec 2008 10:22:38 +0200 From: Dmitrii Dimandt <elliottmatthew@example.net> Reply-To: Dmitrii Dimandt <elliottmatthew@example.net> To: CouchDB <elliottmatthew@example.net> Subject: Simple rereduce introduction tutorial Message-ID: <E9DA60E57154BD96A06C904B@F74D39FA044AA309EAEA14B9> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org Does anyone have an easy-to-understand introduction to/tutorial on the=20 rereduce argument in the reduce function? I *sort of* understand why it's there and I have a vague understanding of=20 how to work with it, but this understanding is just that =E2=80=94 vague. What I would really like to see is a couple of examples and explanations on = how and when it should be taken into account when creating the reduce=20 function From couchdb-user-returnelliottmatthew@example.net Mon Dec 01 11:22:23 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 83782 invoked from network); 1 Dec 2008 11:22:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Dec 2008 11:22:23 -0000 Received: (qmail 62988 invoked by uid 500); 1 Dec 2008 11:22:33 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 62925 invoked by uid 500); 1 Dec 2008 11:22:32 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 62913 invoked by uid 99); 1 Dec 2008 11:22:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 03:22:32 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO assmule.apisnetworks.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 11:21:01 +0000 Received: from [83.161.120.155] (206-248-172-247.dsl.teksavvy.com [83.161.120.155]) by assmule.apisnetworks.com (Postfix) with ESMTPSA id 5904E2745BF for <elliottmatthew@example.net>; Mon, 1 Dec 2008 06:21:47 -0500 (EST) Message-ID: <elliottmatthew@example.net> Date: Mon, 01 Dec 2008 06:23:45 -0500 From: Jedediah Smith <elliottmatthew@example.net> User-Agent: Thunderbird 83.161.120.155 (Windows/20080914) MIME-Version: 1.0 To: elliottmatthew@example.net Subject: Re: Simple rereduce introduction tutorial References: <E9DA60E57154BD96A06C904B@F74D39FA044AA309EAEA14B9> In-Reply-To: <E9DA60E57154BD96A06C904B@F74D39FA044AA309EAEA14B9> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views I just updated that page with a more detailed explanation of reduce and rereduce. Rereduce must *always* be taken into account, though it can often be handled implicitly by the same code as reduce. Here is a simple example of a view in which that is not the case: http://github.com/jchris/couchrest/tree/master/examples/word_count/views/markov Dmitrii Dimandt wrote: > Does anyone have an easy-to-understand introduction to/tutorial on the > rereduce argument in the reduce function? > > I *sort of* understand why it's there and I have a vague understanding > of how to work with it, but this understanding is just that — vague. > > What I would really like to see is a couple of examples and explanations > on how and when it should be taken into account when creating the reduce > function > From couchdb-user-returnelliottmatthew@example.net Mon Dec 01 12:57:03 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 18005 invoked from network); 1 Dec 2008 12:57:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Dec 2008 12:57:03 -0000 Received: (qmail 12934 invoked by uid 500); 1 Dec 2008 12:57:14 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 12443 invoked by uid 500); 1 Dec 2008 12:57:13 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 12432 invoked by uid 99); 1 Dec 2008 12:57:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 04:57:13 -0800 X-ASF-Spam-Status: No, hits=1.8 required=10.0 tests=MIME_QP_LONG_LINE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elliottmatthew@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO fk-out-0910.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 12:55:42 +0000 Received: by fk-out-0910.google.com with SMTP id 19so2455314fkr.12 for <elliottmatthew@example.net>; Mon, 01 Dec 2008 04:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding:content-disposition:sender; bh=eV/zBvMTCOwdkzxBDedQIDjfG4SP5VzLe9JVZnw2mGM=; b=ZrjeKtMWslwbHzLtUOFHXgabhkXUhgA0H9mnbhNTNjJ1Yp5lCeegKhRbGVq89OfLy1 8UG/qOn7R1AGCrsBhPH+4d9n92XSDhXS0hS2eypJj3nSzACiqXXOIFnGOa9HhSaTszJZ L30Nb3opWCZOS/b0j7I+9WPfKQDaSl6a/aXuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:to:subject:message-id:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding :content-disposition:sender; b=ooyOdcTFr3UQTa24vJcG05nLb5LpAFE5rnTrGO8MFFU04K8/8p2/MNiqQFZKBuM9ot bVGuIDxlvQMjsbOY670I63EbKJTH2A6jiYntG+paozvgyfGnmH+yF7Ttmj9gJuo0YWBS CpqJoy34mB5+remJr4JZUCHPym4JuGZJbLX6w= Received: by 83.161.120.155 with SMTP id n16mr2594328fap.20.1228136188918; Mon, 01 Dec 2008 04:56:28 -0800 (PST) Received: from ?83.161.120.155? ([83.161.120.155]) by mx.google.com with ESMTPS id k29sm9037683fkk.37.283.161.120.155.56.27 (version=SSLv3 cipher=RC4-MD5); Mon, 01 Dec 2008 04:56:28 -0800 (PST) Date: Mon, 01 Dec 2008 14:56:24 +0200 From: Dmitrii Dimandt <elliottmatthew@example.net> Reply-To: Dmitrii Dimandt <elliottmatthew@example.net> To: elliottmatthew@example.net Subject: Re: Simple rereduce introduction tutorial Message-ID: <A42F39B19C6DFA0D99221ABD@75B516069BE3C3F7448BC409> In-Reply-To: <elliottmatthew@example.net> References: <E9DA60E57154BD96A06C904B@F74D39FA044AA309EAEA14B9> <elliottmatthew@example.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: Dmitrii Dimandt <elliottmatthew@example.net> X-Virus-Checked: Checked by ClamAV on apache.org --On December 1, 2008 6:23:45 AM -0500 Jedediah Smith=20 <elliottmatthew@example.net> wrote: > > http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views > > I just updated that page with a more detailed explanation of reduce and > rereduce. > Thank you! The list of intermediate values in the explanation cleared=20 everything for me :) > Rereduce must *always* be taken into account, though it can often be > handled implicitly by the same code as reduce. > In my case it was as simple as calculating sums of money, so the code will=20 remain the same :) > Here is a simple example of a view in which that is not the case: > http://github.com/jchris/couchrest/tree/master/examples/word_count/views/ > markov > Yeah, I looked at it and couldn't wrap my head around it :) Now everythng=20 is much clearer :) > Dmitrii Dimandt wrote: >> Does anyone have an easy-to-understand introduction to/tutorial on the >> rereduce argument in the reduce function? >> >> I *sort of* understand why it's there and I have a vague understanding >> of how to work with it, but this understanding is just that =E2=80=94 = vague. >> >> What I would really like to see is a couple of examples and explanations >> on how and when it should be taken into account when creating the reduce >> function >> > From couchdb-user-returnelliottmatthew@example.net Mon Dec 01 16:30:12 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 5562 invoked from network); 1 Dec 2008 16:30:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Dec 2008 16:30:11 -0000 Received: (qmail 48186 invoked by uid 500); 1 Dec 2008 16:30:22 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 48144 invoked by uid 500); 1 Dec 2008 16:30:22 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 48133 invoked by uid 99); 1 Dec 2008 16:30:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 08:30:22 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elliottmatthew@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-qy0-f10.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 16:28:53 +0000 Received: by qyk3 with SMTP id 3so1577237qyk.12 for <elliottmatthew@example.net>; Mon, 01 Dec 2008 08:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=Af+UrO6uUw8q6AtBweby04/YIsV8zgpDwFE22iLQCdA=; b=ZVAQ4J3YMV1SkU/QPeMWvc+QGUrzvwbLH3eIHmDp9jwFC+TVm+970h3iWmBvBYCgBh hztuAkaZiBx7+P5P1hNmdcXTJvzHNICXIprs3BVNmVk+c/DNX9mwRCVX0rWLOc6bY6Zp l+xAhv1x0MhKDzrGTaAWsOqcJvX3/BrzT1d/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=J7EBomxe+aJnrSIsOLqo5BD6kcG4nwFCUDhfZNUyPUM184dJTRunQfQ7qtdwfE8Euu VoiC83Gvew3CR3bT8mBDwB7jGb2711BTbLT5S2jmWavmKzqTAz5aIlGZ3K6F6dAm0hUB zfdu+iDyRJourOzLcZEb7anWFFB5XCfZPXWzo= Received: by 83.161.120.155 with SMTP id t14mr9920793qaj.338.1228148979870; Mon, 01 Dec 2008 08:29:39 -0800 (PST) Received: by 83.161.120.155 with HTTP; Mon, 1 Dec 2008 08:29:39 -0800 (PST) Message-ID: <elliottmatthew@example.net> Date: Mon, 1 Dec 2008 10:29:39 -0600 From: "Jason Huggins" <elliottmatthew@example.net> Sender: elliottmatthew@example.net To: elliottmatthew@example.net Subject: Auto-adding additional fields on PUT/POST? (datetime stamps) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 583ee4a8cd20e92e X-Virus-Checked: Checked by ClamAV on apache.org Hello all! I would like some meta-data to get inserted into documents when my users create them. At a minimum, something like Created and LastModified datetime stamps would be nice. Currently, the users have to manually add these fields when they POST or PUT. Ideally, there is something I can do on the server side to "automagically" add those fields for them. I think the easiest thing to do is to create a DBNotificationUpdate script that looks for new documents and updates them with the datetime data as a document revision. Is there a better way to handle this? I think I want something like what happens now with the creation of the "_id" field... If "_id" is missing, CouchDB will add it to the document on the user's behalf at document creation time. Thanks, and happy couching! -jason http://saucelabs.com From couchdb-user-returnelliottmatthew@example.net Mon Dec 01 19:40:01 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 12681 invoked from network); 1 Dec 2008 19:40:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Dec 2008 19:40:01 -0000 Received: (qmail 23850 invoked by uid 500); 1 Dec 2008 19:40:11 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 23565 invoked by uid 500); 1 Dec 2008 19:40:11 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 23554 invoked by uid 99); 1 Dec 2008 19:40:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 11:40:10 -0800 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO relay03.pair.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 01 Dec 2008 19:38:41 +0000 Received: (qmail 53417 invoked from network); 1 Dec 2008 19:38:25 -0000 Received: from 83.161.120.155 (HELO ?83.161.120.155?) (83.161.120.155) by relay03.pair.com with SMTP; 1 Dec 2008 19:38:25 -0000 X-pair-Authenticated: 83.161.120.155 Message-Id: <elliottmatthew@example.net> From: Damien Katz <elliottmatthew@example.net> To: elliottmatthew@example.net In-Reply-To: <elliottmatthew@example.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: Ordering by values calculated by a map/reduce Date: Mon, 1 Dec 2008 14:38:26 -0500 References: <elliottmatthew@example.net> <elliottmatthew@example.net> X-Mailer: Apple Mail (2.929.2) X-Virus-Checked: Checked by ClamAV on apache.org On Dec 1, 2008, at 3:02 AM, Antony Blakey wrote: > > On 01/12/2008, at 6:09 PM, Ben Bangert wrote: > >> I want to solve what I thought was a fairly simple problem, though >> unfortunately it seems to be rather tricky. I asked on the IRC >> channel, and got some good input, but neither really seemed like a >> very good solution. >> >> The problem: >> >> I want to allow users to rate things. They do this very very >> frequently, so I can't store it in the actual document being rated, >> so I have Rating documents. It's easy enough to write a map/reduce >> that gives me the computed average rating for a given document, >> however, it seems to be impossible to get a listing of the highest >> rated documents, as I can only get the computed rating for a >> document one at a time. >> >> The possible solutions: >> - Buffer rating additions, then at a later time, run through them >> and calculate the new average rating, store it in the document as >> computed_rating, so I can order on that in the key >> - Cron a job that goes in and looks for new rating every 5 mins or >> whatever, and then does the same as the previous solution by >> storing it in a computed_rating field >> >> I'm not a fan of either of these, because #1 means if my webapp >> hiccups, I lose ratings, and #2 is just a pain to keep sweeping the >> db for new Rating documents then going through updating all the >> documents. >> >> Is there really no other solutions that don't require me to store >> the computed rating in the doc itself? There's no way I can perhaps >> order on the value from the map/reduce, rather than only being able >> to order on the key? > > I use an external query handler to solve problems that don't fit map/ > reduce. > > I've modified Paul Davis's _external handler to pass the current > update_seq whenever an external query is made. In the external > process (ruby in my case) I maintain a SQLite database that I can > use for queries that Couch isn't suited for. Whenever a query comes > in, I compare the supplied update_seq with one stored in my sqlite > db (of course I cache that in memory as long as the process lives). > If the sqlite db is out of date, then I do a _all_docs_by_seq and > update sqlite, including the update_seq record, before doing the > (SQL) query and responding with a JSON document in the same format > as Couch would. > > I can delete the sqlite db at any time (well, while the process is > stopped) because it will get recreated/updated when a query comes in > as necessary. This works with replication. > > This system has the same lazy-update characteristics as Couch views, > and has the additional advantage that you can do in-memory caching > in the external process which depending on your update frequency, > means you rarely hit the db. Excellent! What you have created, I think, is a custom view engine. I hope to see more of this (Lucene FT indexing support is another example), maybe you could write up how you did it? Can review the code or design first, if it helps. -Damien From couchdb-user-returnelliottmatthew@example.net Mon Dec 01 19:41:23 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 14855 invoked from network); 1 Dec 2008 19:41:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Dec 2008 19:41:23 -0000 Received: (qmail 29383 invoked by uid 500); 1 Dec 2008 19:41:32 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 29355 invoked by uid 500); 1 Dec 2008 19:41:32 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 29344 invoked by uid 99); 1 Dec 2008 19:41:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 11:41:32 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elliottmatthew@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-qy0-f10.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 19:40:03 +0000 Received: by qyk3 with SMTP id 3so1766071qyk.12 for <elliottmatthew@example.net>; Mon, 01 Dec 2008 11:40:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=3TRqgGoGZ6pnNpdbq7LQD3z67auCX9HxsVq0T5PKj+A=; b=h7sDgudzSLFNnDZ5DHpol/DCIsWeWfqJEWoZtLTS2JEFEZfmMxyPlVbJpxoy/+CabD oM8+rqPiYfa6gW2+09UzZAhTdTVFuo1UQPtIKP6aoTC96k9EWN112+y7swFNsnwchkIA 7qSt0MWcQ2adhfbOZ3Agq4iu6XHFxj0O1bnxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=NMqFlQdKllBzYeaNCxGyfhLPG8xy4ricEhLquVpUJZJXj7q3Ms8qrcdMCnoq03R/AN Dbk2oFkOjjfKfnT9BVZoeaoDRYgvyj0RJ/++myOsLLSnLvBaO7/eVszFz5gIS/sTH1tF Q5A0mBP8UemVvWmGSwZMfw9rPEYn+qwWliMJI= Received: by 83.161.120.155 with SMTP id h18mr11951241qbf.27.1228160449434; Mon, 01 Dec 2008 11:40:49 -0800 (PST) Received: by 83.161.120.155 with HTTP; Mon, 1 Dec 2008 11:40:49 -0800 (PST) Message-ID: <elliottmatthew@example.net> Date: Mon, 1 Dec 2008 11:40:49 -0800 From: "Chris Anderson" <elliottmatthew@example.net> Sender: elliottmatthew@example.net To: elliottmatthew@example.net Subject: Re: Ordering by values calculated by a map/reduce In-Reply-To: <elliottmatthew@example.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <elliottmatthew@example.net> X-Google-Sender-Auth: d59ea919e32fbc0a X-Virus-Checked: Checked by ClamAV on apache.org Something like Antony's external handler could be generalized to keep an up to date version of the full results from a group=true reduce query, stored in a secondary database. There are some old threads on the topic, although I'm having trouble bringing them up just now. (Googled "remap") Anyway, by keeping group reduce results (each row to its own document) in another db, you could define a view that ordered them by value. This functionality would be generally useful and could be implemented as an _external, or as regular script triggered by cron. Chris On Sun, Nov 30, 2008 at 11:39 PM, Ben Bangert <elliottmatthew@example.net> wrote: > I want to solve what I thought was a fairly simple problem, though > unfortunately it seems to be rather tricky. I asked on the IRC channel, and > got some good input, but neither really seemed like a very good solution. > > The problem: > > I want to allow users to rate things. They do this very very frequently, so > I can't store it in the actual document being rated, so I have Rating > documents. It's easy enough to write a map/reduce that gives me the computed > average rating for a given document, however, it seems to be impossible to > get a listing of the highest rated documents, as I can only get the computed > rating for a document one at a time. > > The possible solutions: > - Buffer rating additions, then at a later time, run through them and > calculate the new average rating, store it in the document as > computed_rating, so I can order on that in the key > - Cron a job that goes in and looks for new rating every 5 mins or whatever, > and then does the same as the previous solution by storing it in a > computed_rating field > > I'm not a fan of either of these, because #1 means if my webapp hiccups, I > lose ratings, and #2 is just a pain to keep sweeping the db for new Rating > documents then going through updating all the documents. > > Is there really no other solutions that don't require me to store the > computed rating in the doc itself? There's no way I can perhaps order on the > value from the map/reduce, rather than only being able to order on the key? > > Thanks, > Ben -- Chris Anderson http://jchris.mfdz.com From couchdb-user-returnelliottmatthew@example.net Mon Dec 01 23:04:41 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 97263 invoked from network); 1 Dec 2008 23:04:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Dec 2008 23:04:41 -0000 Received: (qmail 57464 invoked by uid 500); 1 Dec 2008 23:04:51 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 57424 invoked by uid 500); 1 Dec 2008 23:04:51 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 57413 invoked by uid 99); 1 Dec 2008 23:04:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 15:04:51 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elliottmatthew@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO ti-out-0910.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 23:03:22 +0000 Received: by ti-out-0910.google.com with SMTP id w7so1942576tib.6 for <elliottmatthew@example.net>; Mon, 01 Dec 2008 15:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=imCcqVvT2nOhlzRiAmy3+utywOarha4fJHqhn+Yf2lQ=; b=dbHhvAdri2le+3sTRqVx86UxRDm+sNLFqd7KAZVTUQaE194Qim3BoLrJFnwSpDIkiZ iR+vE7MbI7SHMTokbE9Qp5hxnEG9wcz4o2H/smCpRZ+iMNTTQyphk0qrkp1vg61JQeh+ P8Wx/Abil5T4KIoxLQV+6q8t4pyv67uiw52xo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=IzkewSLMrFmDVmF3ENlgsMkbzgI54Mp8XlF0FHHuV28cfSVtICk2hNhiwgMpJmTsZ1 fYwRoSE1zF9l3YJVRPETmYoqpjmhpuW7XpQ/uFZYEmxG+W2MyWICKVPhGQIfFJBy+Dvt 53hFKyueujsLT/J1zjh9A8w8/ac0fBTBOENLg= Received: by 83.161.120.155 with SMTP id 9mr17112436tip.6.1228172648359; Mon, 01 Dec 2008 15:04:08 -0800 (PST) Received: from ?83.161.120.155? (ppp121-45-41-103.lns10.adl2.internode.on.net [83.161.120.155]) by mx.google.com with ESMTPS id b4sm2228058tic.2.283.161.120.155.04.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Dec 2008 15:04:07 -0800 (PST) Message-Id: <elliottmatthew@example.net> From: Antony Blakey <elliottmatthew@example.net> To: elliottmatthew@example.net, Damien Katz <elliottmatthew@example.net> In-Reply-To: <elliottmatthew@example.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: Ordering by values calculated by a map/reduce Date: Tue, 2 Dec 2008 09:34:00 +1030 References: <elliottmatthew@example.net> <elliottmatthew@example.net> <elliottmatthew@example.net> X-Mailer: Apple Mail (2.929.2) X-Virus-Checked: Checked by ClamAV on apache.org On 02/12/2008, at 6:08 AM, Damien Katz wrote: > What you have created, I think, is a custom view engine. Yes. I'd also like to allow an _all_docs_by_seq request over the external control stream so that the external doesn't have to make an HTTP request, which would IMO improve performance and clean up this pattern. > I hope to see more of this (Lucene FT indexing support is another > example), maybe you could write up how you did it? Can review the > code or design first, if it helps. Sure, I'll post once I have a moment to package and clean up the code. BTW: There are a number of different ways to greatly increase server performance using notification driven caching - do you have a any response to my post in couchdb-user titled "Write/Read/Notification synchronization" ? Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If a train station is a place where a train stops, what's a workstation? From couchdb-user-returnelliottmatthew@example.net Tue Dec 02 00:55:49 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 37823 invoked from network); 2 Dec 2008 00:55:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Dec 2008 00:55:49 -0000 Received: (qmail 52584 invoked by uid 500); 2 Dec 2008 00:55:59 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 52552 invoked by uid 500); 2 Dec 2008 00:55:59 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 52541 invoked by uid 99); 2 Dec 2008 00:55:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 16:55:59 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO assmule.apisnetworks.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 00:54:29 +0000 Received: from [83.161.120.155] (206-248-172-247.dsl.teksavvy.com [83.161.120.155]) by assmule.apisnetworks.com (Postfix) with ESMTPSA id 60CC7274624 for <elliottmatthew@example.net>; Mon, 1 Dec 2008 19:54:46 -0500 (EST) Message-ID: <elliottmatthew@example.net> Date: Mon, 01 Dec 2008 19:56:40 -0500 From: Jedediah Smith <elliottmatthew@example.net> User-Agent: Thunderbird 83.161.120.155 (Windows/20080914) MIME-Version: 1.0 To: elliottmatthew@example.net Subject: Re: Auto-adding additional fields on PUT/POST? (datetime stamps) References: <elliottmatthew@example.net> In-Reply-To: <elliottmatthew@example.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org The new validation functions might be able to do this for you if they are allowed to modify the document. Whether or not they are was asked on the dev list but not answered. I hope they are as that would be endlessly useful. It would be *really* neat if a function could also handle merging for revision conflicts. Jason Huggins wrote: > Hello all! > > I would like some meta-data to get inserted into documents when my > users create them. At a minimum, something like Created and > LastModified datetime stamps would be nice. Currently, the users have > to manually add these fields when they POST or PUT. Ideally, there is > something I can do on the server side to "automagically" add those > fields for them. > > I think the easiest thing to do is to create a DBNotificationUpdate > script that looks for new documents and updates them with the datetime > data as a document revision. > > Is there a better way to handle this? I think I want something like > what happens now with the creation of the "_id" field... If "_id" is > missing, CouchDB will add it to the document on the user's behalf at > document creation time. > > Thanks, and happy couching! > > -jason > http://saucelabs.com > From couchdb-user-returnelliottmatthew@example.net Tue Dec 02 03:08:38 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 83672 invoked from network); 2 Dec 2008 03:08:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Dec 2008 03:08:38 -0000 Received: (qmail 33606 invoked by uid 500); 2 Dec 2008 03:08:48 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 33578 invoked by uid 500); 2 Dec 2008 03:08:48 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 33567 invoked by uid 99); 2 Dec 2008 03:08:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 19:08:48 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elliottmatthew@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-qy0-f10.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 03:07:19 +0000 Received: by qyk3 with SMTP id 3so1943710qyk.12 for <elliottmatthew@example.net>; Mon, 01 Dec 2008 19:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=X0aNCbgRJJW7bW7fbdq6ff+eMo5XkaMJy9RNpyUYNO0=; b=Gv1pagpruts6uWHElUxJnqXRrusVa/9hqPo13l+75LTJIn+/4wBFBC3IEDoglYy8+k ogBbyiYVeNAowo9dz0jJs3eyXCSn0SIkkW6oHmxAMkA3qtgALYxBfJ+tjuwOF0+TEihz WX24ngfnzW9aD1IEfL+coYPXtF+VBsP+BIUo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Uat4nfIQshouk6TYozNjRhde9v7/uJfnLBO1Go8DFMM9lP3NaX/Bprp6oUbeGlfLM1 mL6Gx3lJb3EdkmXqN4kUt3UqMOzv2z3ghLNMogZjht1yeO73KuamIzVizyzWlvb866zX tYkUYQ2foI+kr+k+HSQyPLnMIs+j1TCNXuP/w= Received: by 83.161.120.155 with SMTP id 12mr10875977qak.117.1228187226323; Mon, 01 Dec 2008 19:07:06 -0800 (PST) Received: by 83.161.120.155 with HTTP; Mon, 1 Dec 2008 19:07:06 -0800 (PST) Message-ID: <elliottmatthew@example.net> Date: Mon, 1 Dec 2008 21:07:06 -0600 From: "Jason Huggins" <elliottmatthew@example.net> Sender: elliottmatthew@example.net To: elliottmatthew@example.net Subject: Re: Auto-adding additional fields on PUT/POST? (datetime stamps) In-Reply-To: <elliottmatthew@example.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <elliottmatthew@example.net> <elliottmatthew@example.net> X-Google-Sender-Auth: 78590cb808096a6b X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Dec 1, 2008 at 6:56 PM, Jedediah Smith <elliottmatthew@example.net> wrote: > The new validation functions might be able to do this for you if they are > allowed to modify the document. Whether or not they are was asked on the dev > list but not answered. I hope they are as that would be endlessly useful. It > would be *really* neat if a function could also handle merging for revision > conflicts. Are validation functions in trunk or a released version?... or still on the drawing board? (I suppose I should switch to the dev list to ask that question to a more targeted audience.) :-) I have another idea for tracking timestamps and other meta-data. I think I'll create a meta-data database for each "real" database. Since I'd like to give my users free reign to edit their own documents in the real database, but *not* be able to edit createdAt and lastModified timestamps. So, with a meta-data db, I can set it up so only my server has write permission to that meta-db, but the user can read from it. The downside is that combining the data and meta-data into a unified view of the document would have to happen on the client side, not on the couchdb side, since (as I understand it), couchdb can't do cross-database map/reducing views. - jason huggins http://saucelabs.com From couchdb-user-returnelliottmatthew@example.net Tue Dec 02 04:07:07 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 94748 invoked from network); 2 Dec 2008 04:07:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Dec 2008 04:07:07 -0000 Received: (qmail 69463 invoked by uid 500); 2 Dec 2008 04:07:17 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 69434 invoked by uid 500); 2 Dec 2008 04:07:17 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 69423 invoked by uid 99); 2 Dec 2008 04:07:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2008 20:07:17 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elliottmatthew@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-gx0-f12.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 04:05:47 +0000 Received: by gxk5 with SMTP id 5so348771gxk.12 for <elliottmatthew@example.net>; Mon, 01 Dec 2008 20:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=vs3spRE5/rHuloTglOVqbpBy2epzOLP7KY4AVnZA69I=; b=dWhtNWFj3mIDVRvE502bPWX08NpMGAOrKHU5g9owIQDI2o6l6IasKaMtxAEH6DpsSX eXP6mrvbyM/EUySBsHGsUUnWg2uSV84EafszHqVCuV/+9kwagCjPedE307qZPYjI1kp8 m5yp2RvuXgnYCZa/OjGRgP5V5sqZppswR6b98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=SEArcgTHcAoBuyi156rKvcUjAlD1LG6Fcnq7ThcWUGBI1gHoE1vOdnfGuYrwzL+pUr iR8jQJQVFBLzVK0RxCkVecIHRWmJODSqEFkdHVXKXf2884SLQZ+TJeCQetgLYFeigSLP r/gkFMit21r4s4Efv9w0hFcmkg0bZ0DuH9tNg= Received: by 83.161.120.155 with SMTP id g1mr12439381qbf.26.1228190793460; Mon, 01 Dec 2008 20:06:33 -0800 (PST) Received: by 83.161.120.155 with HTTP; Mon, 1 Dec 2008 20:06:33 -0800 (PST) Message-ID: <elliottmatthew@example.net> Date: Mon, 1 Dec 2008 20:06:33 -0800 From: "Chris Anderson" <elliottmatthew@example.net> Sender: elliottmatthew@example.net To: elliottmatthew@example.net Subject: Re: Auto-adding additional fields on PUT/POST? (datetime stamps) In-Reply-To: <elliottmatthew@example.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <elliottmatthew@example.net> <elliottmatthew@example.net> <elliottmatthew@example.net> X-Google-Sender-Auth: 74f46df376f7442a X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Dec 1, 2008 at 7:07 PM, Jason Huggins <elliottmatthew@example.net> wrote: > On Mon, Dec 1, 2008 at 6:56 PM, Jedediah Smith > <elliottmatthew@example.net> wrote: >> The new validation functions might be able to do this for you if they are >> allowed to modify the document. Whether or not they are was asked on the dev >> list but not answered. I hope they are as that would be endlessly useful. It >> would be *really* neat if a function could also handle merging for revision >> conflicts. I'm not sure about changing documents -- I think it would be simple to add if the demand is strong. > Are validation functions in trunk or a released version?... or still > on the drawing board? (I suppose I should switch to the dev list to > ask that question to a more targeted audience.) :-) > I wrote up my dive through the security_validation tests here: http://jchris.mfdz.com/code/2008/12/couchdb_edge__security_and_vali Validations are in trunk, but you'd have to do some work to use them in an application. -- Chris Anderson http://jchris.mfdz.com From couchdb-user-returnelliottmatthew@example.net Tue Dec 02 08:00:29 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 82344 invoked from network); 2 Dec 2008 08:00:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Dec 2008 08:00:29 -0000 Received: (qmail 28765 invoked by uid 500); 2 Dec 2008 08:00:39 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 28734 invoked by uid 500); 2 Dec 2008 08:00:39 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 28723 invoked by uid 99); 2 Dec 2008 08:00:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 00:00:39 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO assmule.apisnetworks.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 07:59:09 +0000 Received: from [83.161.120.155] (206-248-172-247.dsl.teksavvy.com [83.161.120.155]) by assmule.apisnetworks.com (Postfix) with ESMTPSA id 2C63C20A48 for <elliottmatthew@example.net>; Tue, 2 Dec 2008 02:59:56 -0500 (EST) Message-ID: <elliottmatthew@example.net> Date: Tue, 02 Dec 2008 03:01:53 -0500 From: Jedediah Smith <elliottmatthew@example.net> User-Agent: Thunderbird 83.161.120.155 (Windows/20080914) MIME-Version: 1.0 To: elliottmatthew@example.net Subject: Re: Auto-adding additional fields on PUT/POST? (datetime stamps) References: <elliottmatthew@example.net> <elliottmatthew@example.net> <elliottmatthew@example.net> <elliottmatthew@example.net> In-Reply-To: <elliottmatthew@example.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org If validations could write, they could serve as a complete data access layer. They could handle meta data generation, merging, encapsulation (aka implementation hiding/abstraction/conversion) and essentially solve the partial update problem. If merges could be handled by script functions, two-way replication could be completely autonomous. Plus, sloppy developers would be more likely to actually handle revision conflicts instead of just ignoring them. From what I understand of the current architecture, it's most of the way there. There's already a script engine, a way to store scripts associated with an event, a protocol for invoking them and for passing data back and forth. Why not just provide hooks to every part of CouchDB? Chris Anderson wrote: > On Mon, Dec 1, 2008 at 7:07 PM, Jason Huggins <elliottmatthew@example.net> wrote: >> On Mon, Dec 1, 2008 at 6:56 PM, Jedediah Smith >> <elliottmatthew@example.net> wrote: >>> The new validation functions might be able to do this for you if they are >>> allowed to modify the document. Whether or not they are was asked on the dev >>> list but not answered. I hope they are as that would be endlessly useful. It >>> would be *really* neat if a function could also handle merging for revision >>> conflicts. > > I'm not sure about changing documents -- I think it would be simple to > add if the demand is strong. > >> Are validation functions in trunk or a released version?... or still >> on the drawing board? (I suppose I should switch to the dev list to >> ask that question to a more targeted audience.) :-) >> > > I wrote up my dive through the security_validation tests here: > > http://jchris.mfdz.com/code/2008/12/couchdb_edge__security_and_vali > > Validations are in trunk, but you'd have to do some work to use them > in an application. > > From couchdb-user-returnelliottmatthew@example.net Tue Dec 02 09:01:29 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 2676 invoked from network); 2 Dec 2008 09:01:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Dec 2008 09:01:28 -0000 Received: (qmail 87687 invoked by uid 500); 2 Dec 2008 09:01:39 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 87651 invoked by uid 500); 2 Dec 2008 09:01:39 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 87640 invoked by uid 99); 2 Dec 2008 09:01:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 01:01:39 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elliottmatthew@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO rv-out-0708.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 09:00:10 +0000 Received: by rv-out-0708.google.com with SMTP id k29so3541515rvb.0 for <elliottmatthew@example.net>; Tue, 02 Dec 2008 01:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=mK0bKe4jE5LGGmaes+plpoy9k9AyUi0Yk4ogiVQOnYk=; b=qDeITQEfYYPImLXOy+hMTwgtSpwlwh63dD8cnytocNsHRFkN5Gi/06V/lzCooZ9t4J ABYDKoMFhmtqFQAkzEmRjP1RcCebiLqKCCxFFvDSyFKZHgxL/9+HH0Zts4rlx7bL++zf NiGjzbGgwdLeZr6L1dsOCVcKw8aForAwygDJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SJ6dYH3QuTSNUV9oKK95FlUux6vUQzfqI4s5iSGLlGegVxotzcGJVUiyvOPKO8mV23 4Q5oaH7V1yLJQfrdq0Hs7Paw0bOca1lZ6cVE7X9qJBjPhE8QWsMRp0DoT7Cyt9NQ13pm dGCOVfm40al97CVun5Adc7F+/GMyhcYj/4h9k= Received: by 83.161.120.155 with SMTP id u20mr5654102rve.244.1228208448786; Tue, 02 Dec 2008 01:00:48 -0800 (PST) Received: by 83.161.120.155 with HTTP; Tue, 2 Dec 2008 01:00:48 -0800 (PST) Message-ID: <elliottmatthew@example.net> Date: Tue, 2 Dec 2008 04:00:48 -0500 From: "Justin Walgran" <elliottmatthew@example.net> Reply-To: elliottmatthew@example.net To: elliottmatthew@example.net Subject: Re: Hierarchic Atachments/App Deployments (was: Hosting a Cappuccino application from CouchDB) In-Reply-To: <elliottmatthew@example.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <elliottmatthew@example.net> <elliottmatthew@example.net> <elliottmatthew@example.net> <elliottmatthew@example.net> <elliottmatthew@example.net> X-Virus-Checked: Checked by ClamAV on apache.org Damien, I tried adding forward slashes to the file names to simulate a hierarchy as you suggested, but this did not process the invoices any further I filed the following bug report: https://issues.apache.org/jira/browse/COUCHDB-167 -Justin On Fri, Nov 28, 2008 at 6:10 PM, Damien Katz <elliottmatthew@example.net> wrote: > I think should be possible to attach the files using directory slashes right > in the filename. If that doesn't work, file a bug. > > -Damien > > > On Nov 28, 2008, at 5:37 PM, Antony Blakey wrote: > >> >> On 29/11/2008, at 7:39 AM, Justin Walgran wrote: >> >>> That is incredibly helpful. Thank you. >>> >>> To take it a step further, I am very interested in Chris Anderson's >>> work with distributing apps via CouchDB replication. Is there any way >>> the LightsOut application could be incorporated as an attachment like >>> Chris's Twitter application? >> >> Hierarchic attachments would be really useful I think. I could certainly >> use them right now. >> >> Because they don't exist, I'm building a notification handler that listens >> for documents with attributes that indicate that .zip attachments should be >> unpacked. I use a separate DB for such documents (to filter the >> notifications) and it will allow me to replicate existing static websites >> over Couch. >> >> Delta replication of attachments would be useful (e.g. >> XDelta/RSync/Unison) because then I could use either no-compression .zips, >> or .tars, and get much improved replication performance (I do this now in a >> different context). >> >> I'm working on replicating both Smalltalk packages/files and Ruby >> gems/files via Couch with a handler that manages the deployment and >> execution of such processes (driven by a definition document) for deploying >> applications (that use Couch) via Couch. It's particularly useful for >> Smalltalk because Smalltalk scalability is handled by running multiple >> instances on the same box (ST implementations generally use green threads >> with no native multithreading), which I can manage really easily using >> Erlang. >> >> Antony Blakey >> -------------------------- >> CTO, Linkuistics Pty Ltd >> Ph: 0438 840 787 >> >> You can't just ask customers what they want and then try to give that to >> them. By the time you get it built, they'll want something new. >> -- Steve Jobs >> >> >> > > > From couchdb-user-returnelliottmatthew@example.net Wed Dec 03 04:43:17 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 83021 invoked from network); 3 Dec 2008 04:43:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 3 Dec 2008 04:43:17 -0000 Received: (qmail 39680 invoked by uid 500); 3 Dec 2008 04:43:27 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 39637 invoked by uid 500); 3 Dec 2008 04:43:27 -0000 Mailing-List: contact elliottmatthew@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:elliottmatthew@example.net> List-Unsubscribe: <mailto:elliottmatthew@example.net> List-Post: <mailto:elliottmatthew@example.net> List-Id: <couchdb-user.incubator.apache.org> Reply-To: elliottmatthew@example.net Delivered-To: mailing list elliottmatthew@example.net Received: (qmail 39626 invoked by uid 99); 3 Dec 2008 04:43:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2008 20:43:27 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elliottmatthew@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO nf-out-0910.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Dec 2008 04:41:57 +0000 Received: by nf-out-0910.google.com with SMTP id c7so1965931nfi.40 for <elliottmatthew@example.net>; Tue, 02 Dec 2008 20:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=teuYvhzwDbTi9FDvEAUlLkHbhQde7iygjy7xWfEv3yE=; b=YZ4dOOmQ46pwGGVXfHhIGzCi0M37h5/+Qza+A2mfNACYGAZ4uSX5E3zM7nQCxU+pjU LW/4djj+QGasYHHoG31JUoqiDRhM0u7lBZAhOd2Rebwi0jLla/w3hU+EOvGks32Y6cOr ruQO+Ca3H+ytdlWYtMupNCpmDnIT19FhOtdRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=fbfT81UamztnsKRexH1FH5+gTGX0AbGdMJcO3TYf1C7YzsDEW1Ii3CuUHwFqVFi+oy 74v5JzEirq0jkRbcOQKbc0zhjoZUszF7YNqNsmguOjN5iaJIssy+WEb40A65WNTWb6ps qVWpoTFp0UlR6l11Z9W7xq9+9odbvUa35CmYc= Received: by 83.161.120.155 with SMTP id y18mr9652340ebc.123.1228279354217; Tue, 02 Dec 2008 20:42:34 -0800 (PST) Received: by 83.161.120.155 with HTTP; Tue, 2 Dec 2008 20:42:33 -0800 (PST) Message-ID: <elliottmatthew@example.net> Date: Tue, 2 Dec 2008 20:42:33 -0800 From: "Chris Anderson" <elliottmatthew@example.net> Sender: elliottmatthew@example.net To: elliottmatthew@example.net Subject: Re: Auto-adding additional fields on PUT/POST? (datetime stamps) In-Reply-To: <elliottmatthew@example.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <elliottmatthew@example.net> <elliottmatthew@example.net> <elliottmatthew@example.net> <elliottmatthew@example.net> <elliottmatthew@example.net> X-Google-Sender-Auth: f5d37cba0a589ed8 X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Dec 2, 2008 at 12:01 AM, Jedediah Smith <elliottmatthew@example.net> wrote: > > If validations could write, they could serve as a complete data access > layer. They could handle meta data generation, merging, encapsulation (aka > implementation hiding/abstraction/conversion) and essentially solve the > partial update problem. I think I've had a change of heart. Damien argues that people would use validation-writes to generate timestamps. But the timestamps can be wrong/faked (on remote nodes) and there's no way to validate (on replication) that they are correct. So putting stamp-capability into the validation functions would setup false expectations. Apparently it caused all sorts of trouble in Notes. This is an instance of a broader distributed computing axiom: no global clock. > > If merges could be handled by script functions, two-way replication could be > completely autonomous. Plus, sloppy developers would be more likely to > actually handle revision conflicts instead of just ignoring them. It might be best to save this action for the end of replication, as replication could apply more than one replicated rev per document. It would be nice to have a place in design docs for replication conflict revision, but I don't think validation is that place. > > Why not just provide hooks to every part of CouchDB? I think the important thing to do is design them in such a way as to give developers the flexibility they need while maintaining the right expectations about what a distributed database can offer. That said, there is a lot of work to add really cool hooks into CouchDB. One of the most exciting prospects is Comet requests, where you could do a POST to /db/_since_seq?seq=300 and wait for a response until the next change after the last change that you knew about happened. -- Chris Anderson http://jchris.mfdz.com From couchdb-user-returnelliottmatthew@example.net Wed Dec 03 07:10:01 2008 Return-Path: <couchdb-user-returnelliottmatthew@example.net> Delivered-To: elliottmatthew@example.net Received: (qmail 79748 invoked from network); 3 Dec 2008 07:10:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 3 Dec 2008 07:10:01 -0000 Received: (qmail 50836 invoked by uid 500); 3 Dec 2008 07:10:07 -0000 Delivered-To: elliottmatthew@example.net Received: (qmail 50743 invoked by uid 500); 3 Dec 2008 07:10:06 -0000 Mailing-List: contact elliottmatthew@example.net;
{'source': 'Apache Software Foundation Public Mail Archives'}