[bind10-dev] initial ideas on the "difference" design

[Michal 'vorner' Vaner]

Hello

On Wed, Oct 12, 2011 at 12:41:28AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> Whether this design and APIs make sense is the biggest question, but
> if they do, my gut feeling is that it won't be so difficult to
> implement and it's not impossible to complete this framework and
> IXFR-out on top it by the next release (even if we do nothing except
> for design discussions for the first two weeks).

I think it mostly does. But I'd like to point out this design consists of two
levels, one is interface and one is a possible storage method of the diffs.

> Then the stored database rows corresponding to the above example would
> look like this (assume "zone_id" for example.com is 10):
> ID ZID  ver op  name            rrtype
> 1,  10,   1, 0, "example.com.", "SOA",...
> 2,  10,   1, 0, "a.example.com.", "A", ...
> 3,  10,   2, 1, "example.com.", "SOA", ...
> 4,  10,   2, 1, "b.example.com.", "A", ...
> 5,  10,   2, 1, "c.example.com.", "A", ...

What is the reason for having the ID? We don't need to reference exact row of
database ever, so there's no need to have an identifier and I guess the order
inside the diff does not matter provided deletions are first, right? Because the
diff is atomic anyway.

Also, from the interface point of view, I'd say the journaling would be allowed
to write the diffs even if the updater's parameter is False (eg. git-based data
source, where each change is a commit, it generates any differences whenever you
ask).

> select * from diffs where
>   zone_id = Z and
>   id >= (select id from diffs where version = B and operation = 0
>          order by id asc limit 1) 
>   and
>   id <= (select id from diffs where version = E and operation = 1
>          order by id desc limit 1);

Maybe:
  select * from diffs where
  zone_id = Z and
  version >= B and version <= E order by (version, operation);

(With some tweaks, of course). This one looks less complicated and might be
faster. This expects the version, zone id and operation are indices (not
necessarily primary ones).


I'm not sure I'd like a de-coupling of diff-commit from the normal commit. What
happens if the first succeeds and the second does not? Should we delete the
diff? Or try to re-apply it? Or call for help? I think both storing the diff and
the data themself should be part of the same transaction and become atomic.

With regards

-- 
Something is obviously wrong. The thing works.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20111012/aa463ac3/attachment.bin>