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

[JINMEI Tatuya / 神明達哉]

At Mon, 17 Oct 2011 11:40:32 +0200,
Jelte Jansen <jelte at isc.org> wrote:

> Alternatively, we can have two 'soa serial' columns; a from and a to.
> That way, the order in which the records come out of the query isn't
> important and we don't have to rely on it (except perhaps for
> convenience or optimization); you iterate over the results to build up
> the 'diff', and check whether you are encountering a SOA. For every
> other record, the operation columnn should tell whether it is deletion
> or addition.
> 
> Technically, I don't think it even requires such a 'to' column, but it
> should also prevent the necessity to do serial arithmetic on this level.

Whether or not we have the 'to' column, it's true that we could
introduce smartness at a lower level (i.e., rather requiring sorted
data having the backend or its wrapper handle the ordering issue).
I'm not sure if this is a better approach in terms of implementation
(and perhaps also runtime) cost.  Especially when the difference
sequence is big, for example, if we cannot assume a sorted order,
we'll need to maintain a larger buffer to store intermediate data.

I'm also afraid we still need some unique (and probably ordered) ID
field to deal with wrapped serials.  Whether or not we have the 'to'
column, we cannot determine the ordering of multiple difference
sequences, such as: 0 to 2^31 - 2; 2^31 - 2 to 2^32 - 4; 2^32 - 4 to
0.

> >> 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).
> > 
> > I'm afraid I don't understand this...do you mean it should be possible
> > for a data source implementation to record diffs anyway if the higher
> > level begins with "ZoneUpdater(zone, journaling=False)"?  If so, I
> > don't think it's prohibited by this design.  This design only requires
> > diffs must be logged if journaling is True, but doesn't say they must
> > not be logged if it's False.
> 
> I was wondering something like this myself, shouldn't it either always
> keep a record or never do so? And if it should, wouldn't it make more
> sense to have the option on the datasource constructor level?

Hmm, I didn't think about this issue that way, but you're right, if it
should be 'always record' vs 'never record' (as a characteristic of
specific data sources), it may be more reasonable to fix that at the
time of data source (client) construction.

I could imagine, however, some cases where the application might want
to control that per zone basis.  For example, if a zone allowing
dynamic updates is generally believed to be small (e.g. updates are done
only for replacing a small set of records and the entire size of zone
is small), the administrator may rather want to use AXFR than managing
diffs (even though it's automatic under the hood, involving more
features will make the operation more fragile in general).  Also, if a
secondary server updates a zone by IXFR but never intends to allow
outbound transfer, it doesn't need to keep the record (at least not
for the purpose of IXFR-out).

I'm simply not sure how feasible these examples could be.  If many
others would rather fix this property (loggable or not) of a specific
data source, I'm okay with that.  One subtle point is that if we take
this approach, we need to consider how to record DDNS diffs, because
if it's automatically done within data source, we need to introduce
the smartness in a lower level with addressing the related issues as
discussed in the first part of this message.

---
JINMEI, Tatuya