[bind10-dev] revised/refactored data source design proposal

[Michal 'vorner' Vaner]

Hello

I did read the wiki page (I didn't have a look at any of the experiment code),
partly out of curiosity.

I find it reasonable design as overall. But I have few points that worry me a
bit:

 * Naming conventions (might be bikeshedding, but I find that good naming makes
   a big difference in code readability). For one, isn't database single word,
   so it should be written as Database, not DataBase? The second looks like it
   would be some base in which data are encoded, like base64, or so.

   Second, could we use something shorter, using namespaces, nested classes or
   something? Names like DataBaseDataClientCreator are quite long and
   unreadable, they kind of get confused one into another (I was thinking „Oh
   god, this looks too like Java“).

 * You say that each thread will have it's own client, because some databases
   can't share the connection. But on the other hand, we really don't want to
   have multiple instances of the in-memory data loaded in memory, that would be
   both waste of memory and performance penalty. Is it expected that the
   in-memory clients will share the data?

 * You intend to not have transaction for reading operations. I find this wrong,
   as we do multiple queries to the DB per single query. This could produce
   inconsistent data.

   If we provided methods to start and end a read-only transaction, the
   databases supporting this could implement it and the in-memory source would
   just have empty methods and we would ensure the consistency in different way
   for it.

   As we talked about this on the last F2F, we probably don't want the in-memory
   to be directly writable, but somehow reload it from permanent storage when it
   changes. So we could do some kind of atomic reload (be it big read-write log,
   loading in background and replacing the tree, shared pointer tricks and
   consistency, etc).

   So, would it be possible to add a method to it as well? Or some kind of
   transaction-ish object or so?

 * What about stuff that is not supported by a given backend? Would the method
   throw a not-implemented and the above level would take care of it somehow?
   (depending on the feature, if it was attempt to write to it, it would fail,
   but in case it would be some DNSSEC support, it could just assume the zone is
   not signed if the backend doesn't support it).

On Thu, Jun 02, 2011 at 01:58:26AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> Hopefully we can discuss this in the mean time and start actual
> development tasks in the next release cycle.  I also think it would be
> nice if we can discuss this topic in the next biweekly call.

+1

With regards

-- 
How many Lisp programmers does it take to change a light bulb?
(((H)mmm,) (I'm ((not) sure, better))) (find (out))...

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