[bind10-dev] initial ideas on the "difference" design
JINMEI Tatuya / 神明達哉
jinmei at isc.org
Thu Oct 13 06:19:35 UTC 2011
At Wed, 12 Oct 2011 12:20:48 +0100,
Stephen Morris <stephen at isc.org> wrote:
> In general, the statement will be simpler in most cases the versions
> required will not be "B to E" but "B to latest". In that case,
> something like:
>
> select * from
> (select * from diffs where
> zone_id = Z and version >= B
> except
> select * from diffs where
> zone id = Z and version = B and operation = 1)
> order by id asc
>
> That is not quite complete in itself as an additional access will be
> required as we need to check that there is difference information for
> version B in the table. If there isn't, we have to fall back to AXFR.
Cool, but note that we still cannot directly use the versions for
comparison unless we internally convert SOA serials to monotonically
increase numbers.
Anyway, the example of SQL statement is just for reference and
discussion, and purely internal to the lowest level of representation.
As long as we agree on the basic design we can begin with any workable
statement and then optimize it without affecting the other part of the
system.
> > 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.
>
> I agree with that, although I think the decoupling is only in the
> special case where the diffs are stored in a different database to the
> zone. Where they are in the same place, I think doing everything in a
> single transaction is the best idea.
I believe we are on the same page when both diffs and main data are
stored in the same place. So the question is whether we want to allow
the flexibility of separating these two storage in the initial design
of API. In the initial idea it was allowed, but if that is deemed to
be too much for the moment, I'm okay with excluding it.
> In general, the overall design looks good and reflects the way I was
> thinking about the problem.
Okay, good to know that.
---
JINMEI, Tatuya
More information about the bind10-dev
mailing list