Browse Source

updated the the Zone class description with future possible plans of interaction with other data sources. based on a follow-up discussion in code review.

git-svn-id: svn://bind10.isc.org/svn/bind10/branches/trac418@3746 e5f2f494-b856-4b98-b285-d166d9295462
JINMEI Tatuya 14 years ago
parent
commit
62dfb92889
1 changed files with 12 additions and 0 deletions
  1. 12 0
      src/lib/datasrc/zonetable.h

+ 12 - 0
src/lib/datasrc/zonetable.h

@@ -45,6 +45,18 @@ namespace datasrc {
 /// information about the location of a zone file, whether it's loaded in
 /// information about the location of a zone file, whether it's loaded in
 /// memory, etc.
 /// memory, etc.
 ///
 ///
+/// It's not yet clear how the derived zone classes work with various other
+/// data sources when we integrate these components, but one possibility is
+/// something like this:
+/// - If the underlying database such as some variant of SQL doesn't have an
+///   explicit representation of zones (as part of public interface), we can
+///   probably use a "default" zone class that simply encapsulates the
+///   corresponding data source and calls a common "find" like method.
+/// - Some data source may want to specialize it by inheritance as an
+///   optimization.  For example, in the current schema design of the sqlite3
+///   data source, its (derived) zone class would contain the information of
+///   the "zone ID".
+///
 /// <b>Note:</b> Unlike some other abstract base classes we don't name the
 /// <b>Note:</b> Unlike some other abstract base classes we don't name the
 /// class beginning with "Abstract".  This is because we want to have
 /// class beginning with "Abstract".  This is because we want to have
 /// commonly used definitions such as \c Result and \c ZonePtr, and we want
 /// commonly used definitions such as \c Result and \c ZonePtr, and we want