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

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/13/2011 02:26 AM, JINMEI Tatuya / 神明達哉 wrote:
>> 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.
> 
> Two reasons: first, this representation is intended to be used as a
> valid sequence of IXFR, so at least the first RR of each
> "delete"/"add" part must be SOA.  Using IDs and sorting results by ID
> are one convenient way.  
> Second, this representation assumes "version"
> is the SOA serial, so we cannot assume that versions monotonically
> increase and that we can compare them just like bare integers.  On the
> other hand, if these points can be addressed in a different way, it
> doesn't have to be IDs.  (e.g. for the first point, we may want to
> achieve this by introducing 4 different operation types: 0: delete
> SOA, 1: delete other RRs, 2: add SOA, 3: add other RRs, and sort them
> in this order).

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.

(there is a little voice screeching that there will be redundant data
which should be split up into several tables, but I must confesst I
haven't kept up my database design recently :))

> 
>> 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?

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6b+BAACgkQ4nZCKsdOncViIwCgtYwaV2SrDa7hOwDz8Mh6eEI7
xoYAoLptCs0QGuUUoP/GxW/o3Xk9Wnxm
=rIFR
-----END PGP SIGNATURE-----