Re: Auto-adding additional fields on PUT/POST? (datetime stamps)

[Jedediah Smith <je...@silencegreys.com>]

Chris Anderson wrote:
> On Tue, Dec 2, 2008 at 12:01 AM, Jedediah Smith
> <je...@silencegreys.com> 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 CouchDB can't add timestamps then the client has to do it and the 
client is sometimes a web browser. Who's more likely to give you bad data?

If someone needs timestamps in a multi-master db cluster, then they need 
timestamps in a multi-master db cluster. Might as well throw them a 
bone. Anybody in charge of building such a thing is probably somebody 
who doesn't need their hand held anyway. Notes was a user app.. totally 
different situation.

Oddly, I had to deal with this very problem today at work. Some time 
deltas were way off and we discovered that changing the clock on the db 
server affected it. But our problem was that a service was running on 
the wrong server.

>> 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.

Oh, absolutely.. have many handlers each with very specific semantic 
requirements. They'll need a way to share code though.

Comet is cool and it will be needed in a world of short-stack AJAX apps. 
But a feed of all updates will be too much data in some cases. How about 
"live views"? e.g.

/db/_view/email/by_date?follow=true&after_seq=300

But then you need a way to represent removed rows.. seems simple enough:

{"id":"abc", "key":"123", "deleted":true}


Maybe we should move this to couchdb-dev?

Re: Auto-adding additional fields on PUT/POST? (datetime stamps)

[Chris Anderson <jc...@apache.org>]

On Tue, Dec 2, 2008 at 11:10 PM, Jedediah Smith
<je...@silencegreys.com> wrote:
>
> How about "live
> views"? e.g.
>
> /db/_view/email/by_date?follow=true&after_seq=300
>
> But then you need a way to represent removed rows.. seems simple enough:
>
> {"id":"abc", "key":"123", "deleted":true}
>
>

This is essentially how replication via views will work. Replication
views have slightly different semantics (they aren't stored on the
server, for one thing -- it's up to the client to maintain the
replication state.)

As a result their function signature is different (they don't emit as
they aren't sorted by key, just seq #). The client supplies a
replication function, which the server runs across docs in seq order,
replicating docs that match the function. This is looking very
powerful.

Chris

-- 
Chris Anderson
http://jchris.mfdz.com