[bind10-dev] addZone interface for the new loadzone and zone management framework

[Jelte Jansen]

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

On 12/06/2012 10:51 AM, Michal 'vorner' Vaner wrote:
> Hello
> 
> The last problem first, since I see a reasonable solution:
>> Another note related to the topic (but basically orthogonal to
>> the previous point): if we separate the operation of adding a
>> zone and the operation of loading zone data (e.g, not within the
>> same DB transaction), there will be a period when a server
>> recognizes the existence of a zone without its content.  Then,
>> until the load is completed the auth server will return SERVFAIL
>> to queries for the zone.  This is probably not the wanted
>> behavior, and I guess we'll need to provide some way to make both
>> operations atomic.  It will probably affect some of the
>> interfaces we are currently developing.
> 
> I think the addZone should directly return the updater. Or, the
> getUpdater should have a „bool can_add“ parameter. That way, the
> zone is not really there until we commit the updater, which is what
> we want.
> 

yeah, this would be my preferred approach as well, not only for the
commit, but because the calling side would be a bit simpler :) (and
put the can_add into ZoneLoader too, which is what triggered this
discussion). Of course, should we have an addZone() itself,
getUpdater() could use that (but then there is still the commit issue,
and the option to create an empty zone which may not be what we want).

> On Wed, Dec 05, 2012 at 08:38:52PM -0800, JINMEI Tatuya / 神明達哉
> wrote:
>> In the short term, we need to decide whether to take this path or
>> add some sqlite3-specific quick hack to the loadzone code itself.
>> If we choose the former, we should probably lower the priority of
>> some of the existing tickets of the sprint.  Possible candidates
>> would be: #2500 (SOA RDATA support), #2440/#2441
>> (merge/order-free load for in-memory).
> 
> I'd like to note first how I dislike our „short term quick hacks“.
> It seems our „short term“ is very long and we seem to spend very
> much time implementing short-term hacks we throw away later. It
> makes the code quality lower and makes our progress slower (we
> sometimes gain some short-term advantage like having a feature
> available for release, but I don't know if it's worth it).
> 
> In this sense, I think the addZone approach is slightly better.
> Optimally, we would have the discussion about how to store and
> manage zones first (which we failed to have for some long time now
> already), but I understand it's not possible at this stage.
> 

My reasoning was that a workaround would probably be as much work,
even now, actually. The potential problem would be that the interface
might change, but in terms of implementation code, I don't think the
add-zone-to-db code would change for that anyway, so might as well
write that directly there, instead of in another workaround.

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

iEYEARECAAYFAlDAbtYACgkQ4nZCKsdOncXicwCgxiuBpG4CF5gCxGfbwlhvfWEp
16oAoLxg7D0Qb2tWD9NeTvuNUryGZlTW
=eOPM
-----END PGP SIGNATURE-----