I posted more about the way I understand that btree is working. http://ayende.com/Blog/archive/2008/09/24/more-couchdb-reading-btreelookup.aspx http://ayende.com/Blog/archive/2008/09/24/more-couchdb-reading-btreequery_modify.aspx
On Wed, Sep 24, 2008 at 11:43 AM, Ayende Rahien <[EMAIL PROTECTED]> wrote: > On Wed, Sep 24, 2008 at 11:15 AM, Ayende Rahien <[EMAIL PROTECTED]> wrote: > >> On Wed, Sep 24, 2008 at 11:04 AM, Jan Lehnardt <[EMAIL PROTECTED]> wrote: >> >> >>> I have to refer you to Damien or the source for that one. :-) >>> >> >> Trolling the sources now, but it is pretty hard to figure it out. >> > > Okay, here are my current finding. > Views are trees keyed by a different key than the DB. Not sure yet how this > works with regards to sorting on non string data (dates,floats). > > The format of the header of the file is this (for databases, views has > different header): > > Header structure (database): > "gmk\0" > // assuming data is small enough: > db_header: > writer_version > update_seq > summary_stream_state, > fulldocinfo_by_id_btree_state > docinfo_by_seq_btree_state > local_docs_btree_state > purge_seq > purged_docs > // zero padding to 2048 > md5 (including zero padding) > > // else if data is too big > pointer_to_header_data, position in file > // zero padding to 2048 > md5 (including zero padding) > > > notes: > - append_binary leaves the current file position in an undefined position > (see pwrite documentation), but it looks like that is not handled in the > code. > - I am not seeing the header written twice, I am seeing it always written > to pos 0, never to pos 2048 > > more to follow >
