We already have code to read log records and we do not need a type in log edits. We do not call this yet as we do not do crash recovery yet. I saw you already committed some changes for this without waiting for a reply. Please revert your latest commit.
thanks Selcuk On Wed, Mar 14, 2012 at 6:10 AM, Emmanuel Lécharny <[email protected]> wrote: > Hi, > > as i'm reviewing the way we manage the WAL (Write Ahead Log), I have a few > questions : > > 1) UserLogRecord > > It's a data structure encapsulating an opaque byte[] containing a serialized > form of a record. We have two length, the serialized data length, and the > buffer length (which might be wider). > > I guess that the rational is that we first allocate a buffer, and we may > store some smaller data into this buffer. Sounds ok, but the question is why > we can't simply store a full buffer (ie only allocate what we need)? Am I > missing something here ? > > 2) LogEdit > > When we write the LogEdit instance, we have no way to read them back as we > don't know if we have written a TxnChangeState or a DataChangeContainer. > Even for a DataChangeContainer, which contains a list of DataChange (ie > either IndexModification or EntryModification), we have no indication about > the written type. > > I think we need to add an identifier at the begining of the written data > structure to allow the reader to know which kind of object to create, or > again, I'm missing something (like we will always know what kind of object > we are expecting, because they are ordered - unlikely for indexChange, as we > will have a variable number of modified indexes -. > > 3) Reading the log > > I guess we never read the log, so far. Am I right ? Is this a part of the > code we need to implement ? > > Any clues ? > > Thanks ! > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
