View Internal API

[Paul Davis <pa...@gmail.com>]

Dev People,

Its no secret that I've been trying to find a reason to delete all of
the temp_view logic in the view code. I was just discussing the
internal view API with Adam Kocoloski on IRC and it hit me that with
the index-filename-from-md5 patch that Chris Anderson landed a while
ago could make it all go away.

The proposed API would be something like:

couch_view:get_view(DesignDoc) -> #view{}

Where DesignDoc is the ErlJSON representation of that design doc. Then
temp_views would just create the ErlJSON representation (without
saving that doc in the DB) and pass it to the view update mechanics.
Cleaning up old temp views would then just use the existing cleanup
mechanism we already have in place.

AFAICT, this doesn't introduce any sort of oddities that don't already
exist and provides better semantics for promoting a temp_view to a
permanent view because the index wouldn't need to be rebuilt.

Then again I'm a bit tired so I could be off my rocker. Anyone see
anything obviously wrong?

Paul Davis

Re: View Internal API

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

On Sat, Dec 5, 2009 at 7:14 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 24 Nov 2009, at 06:14, Paul Davis wrote:
>
>> Dev People,
>>
>> Its no secret that I've been trying to find a reason to delete all of
>> the temp_view logic in the view code. I was just discussing the
>> internal view API with Adam Kocoloski on IRC and it hit me that with
>> the index-filename-from-md5 patch that Chris Anderson landed a while
>> ago could make it all go away.
>>
>> The proposed API would be something like:
>>
>> couch_view:get_view(DesignDoc) -> #view{}
>>
>> Where DesignDoc is the ErlJSON representation of that design doc. Then
>> temp_views would just create the ErlJSON representation (without
>> saving that doc in the DB) and pass it to the view update mechanics.
>> Cleaning up old temp views would then just use the existing cleanup
>> mechanism we already have in place.
>>
>> AFAICT, this doesn't introduce any sort of oddities that don't already
>> exist and provides better semantics for promoting a temp_view to a
>> permanent view because the index wouldn't need to be rebuilt.
>>
>> Then again I'm a bit tired so I could be off my rocker. Anyone see
>> anything obviously wrong?
>
> The only thing I'd advocate is that we make it more apparent in Futon
> that view cleanup is needed. Otherwise, I like the idea of removing that
> code.
>

So the idea is that this wouldn't change the HTTP API, just how it's
implemented? If so, then by all means yes.

If you are going to work on this, I think it should be done on top of
my design doc handlers patch [1], as I'm already moving the loading of
the design doc to the front of the request handling. The changes
you'll have to make to make this happen will play right into the rest
of that patch.

I'm glad we found a synergy here - I knew the patch would make things
simpler but I didn't realize it would help with this too.

Chris

[1] http://issues.apache.org/jira/browse/COUCHDB-589 (I have done more
work in git, I'll make that available asap)



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Re: View Internal API

[Jan Lehnardt <ja...@apache.org>]

On 24 Nov 2009, at 06:14, Paul Davis wrote:

> Dev People,
> 
> Its no secret that I've been trying to find a reason to delete all of
> the temp_view logic in the view code. I was just discussing the
> internal view API with Adam Kocoloski on IRC and it hit me that with
> the index-filename-from-md5 patch that Chris Anderson landed a while
> ago could make it all go away.
> 
> The proposed API would be something like:
> 
> couch_view:get_view(DesignDoc) -> #view{}
> 
> Where DesignDoc is the ErlJSON representation of that design doc. Then
> temp_views would just create the ErlJSON representation (without
> saving that doc in the DB) and pass it to the view update mechanics.
> Cleaning up old temp views would then just use the existing cleanup
> mechanism we already have in place.
> 
> AFAICT, this doesn't introduce any sort of oddities that don't already
> exist and provides better semantics for promoting a temp_view to a
> permanent view because the index wouldn't need to be rebuilt.
> 
> Then again I'm a bit tired so I could be off my rocker. Anyone see
> anything obviously wrong?

The only thing I'd advocate is that we make it more apparent in Futon
that view cleanup is needed. Otherwise, I like the idea of removing that
code.

Cheers
Jan
--