On Sep 24, 2008, at 4:43 AM, Ayende Rahien 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.
This is because we never rely on the previous position of the FD,
before any operation we set the position explicity. This is because
the FD is read or written to by many processes, so relying on position
between calls is never safe.
- I am not seeing the header written twice, I am seeing it always
written
to pos 0, never to pos 2048
Its written twice but in a single write operation, so the first 2048
duplicated to a single 4096 buffer and the whole written.
more to follow
Good stuff!
