BIND 10 #2044: In-Memory cache in ClientList

[BIND 10 Development]

#2044: In-Memory cache in ClientList
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  vorner                             |                Status:  closed
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120717
  medium                             |            Resolution:  complete
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  7
            Defect Severity:  N/A    |           Total Hours:  5.01
Feature Depending on Ticket:  Use    |
  new datasources                    |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * status:  reviewing => closed
 * totalhours:  0 => 5.01
 * resolution:   => complete


Comment:

 Replying to [comment:10 jelte]:
 > I wonder if we should check whether a zone is present in multiple
 datasources; that might result in some unexpected behaviour (not really
 specific here, but the way they are added to the cache reminded me of it).

 Well, the semantics is that the first instance of the best match takes
 precedence. So, there's no need to. Note that each data source has its own
 separate cache.

 > This seems a lot like running memory datasource that loads from sqlite3
 (except this will hopefully be load-on-demand completely in the future) :)
 Will this replace that or will we have both? (i.e. the to be implemented
 cache_all option).

 Yes, that's a generalization of that, for any data source. I want it to be
 able to detect the zones automatically, so we can omit the list of the
 zones. I want it to replace that, because the current/old way is non-
 systematic hack. I'd like the „memory“ type be gone in the long term (or,
 at least, modify the configuration it takes to something sane).

 Anyway, I don't think an on-demand loading would make sense. Can you
 imagine your `com.` is not yet cached and you get the query? Even if we
 could load it in background, the query would likely time out by then.

 > I don't recall if this would be part of the zoneloaderv2 work., but did
 we intend to change the way zones are loaded in the API? The intermediate
 zonefinder creation seems unnecessary, and things would look simpler if we
 could just call load() directly on InMemoryClient; or perhaps even make it
 a public call of DataSourceClient (in that case we can remove the
 InMemoryClient class from the code here completely, and initialize a base
 datasourceclient as an inmemory one). Though of course the latter would
 need some consideration as to what to do for different types of
 datasource.

 I don't think I parse the question. If you want to explain it, could you
 do it by email (either to me or to -dev)? Thank you

-- 
Ticket URL: <http://bind10.isc.org/ticket/2044#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development