On Thu, Jan 7, 2010 at 2:04 PM, Matteo Caprari <[email protected]> wrote: > Hi Brian. > > To make it short, I'm trying to write a sample couchapp trying to > capture some best practices. I started with using natural ids composed > by an embedded timestamp and the title of the document. I then > switched to server-generted uuids and a separate created_at field than > must be shared by 'master' and 'detail' documents. > > The utc_random is good idea. Does it need to be configured at instance > level? If so, wouldn't it be a problem in distributed environment.
That's the problem with this. You shouldn't use the utc-random part of the uuid to mean anything. It makes no guarantees except being ordered-ish and not very collision-y. > > I'm also starting to appreciate the idea to use to use ids for > uniqueness enforcement only, if anything because there will be at > least one other sorting field (votes). > > -teo > > On Thu, Jan 7, 2010 at 8:55 PM, Brian Candler <[email protected]> wrote: >> On Wed, Jan 06, 2010 at 01:42:56PM -0800, Chris Anderson wrote: >>> > emit([ >>> > doc.question_created_at, >>> > doc.question_id, >>> > (doc.question) ? 0 : 1], doc) >>> >>> That's good. I hadn't thought of that. >>> >>> One concern is clock drift between clients. Another is validating that >>> the client hasn't changed the question_created_at. >> >> But if you embed the created_at time within the doc's _id, then it can't be >> changed. So don't keep a created_at timestamp at all; just use >> >> [uuids] >> algorithm = utc_random >> >> Take the first 14 characters of the _id whenever you want to know the >> created_at time. >> >> I haven't been following the details of this thread, but if you have >> separate answer documents I think they can have a pointer to the >> question_id, which is naturally ordered by date using the utc_random uuid >> algorithm. >> > > > > -- > :Matteo Caprari > [email protected] > -- Chris Anderson http://jchrisa.net http://couch.io
