[bind10-dev] Datasource API

[Jelte Jansen]

On 01/05/2010 08:51 PM, Shane Kerr wrote:
> 
> Right. We also may want to implement read-only back-ends (for example).
> Programs that want to use the API to update data sources need to have a
> way to check whether imports/updates are possible. (Is there a
> difference? Can we reasonably envision a data source that we can import
> to but not then subsequently update?)
> 

nope, but i can certainly think of a few where both are done externally

>>
>> ps. we'll probably need a more advanced getRRset(), and i have not
>> thought about how we could do history for ixfr at all yet
> 
> We spent quite a few cycles talking about this at the first BIND 10
> face-to-face meeting. Fundamentally we need something like a transaction
> for any data source that can be updated.
> 

i am not as daunted by having a transaction model as i am by needing
some form of change history for outbound ixfr...

> An API could look a lot like BIND 9, which basically creates an update
> context and locks the database AIUI. This can be BEGIN/COMMIT in an SQL
> database... although probably we want to insure we have the correct
> transaction isolation level (serializable is best, but possibly other
> levels are acceptable and give much improved performance... SQLite does
> serializable by default, PostgreSQL and MySQL need a bit of convincing):
> 
> http://www.sqlite.org/sharedcache.html
> http://www.postgresql.org/docs/8.4/interactive/transaction-iso.html
> http://dev.mysql.com/doc/refman/5.5/en/set-transaction.html
> 
> We can make serials either implicit or explicit in this. I think keeping
> them implicit makes sense as it allows concurrent processing, although
> we may then need to add some special handling if the SOA itself is
> modified.
> 

implicit as in automatically-changed? we'll need explicits then anyway

> 
> An API could also perhaps look a bit like a DDNS update, where you
> collect all of your operations and then submit it at once. I'm not sure
> how practical this is, because we would need to collect a set of reads
> together without knowing exactly what they are (I think). So unless
> someone wants to explore this I think we need to go with the transaction
> model for updates.
> 

yes

> 
> We need some sort of transaction, as mentioned above. We may want to
> always have this for every operation, although conceivably some
> shortcuts are nice. So, basically a factory method as part of the
> DataSource:
> 
>     Transaction beginTrans();
> 
> In this case, we move almost all operations out of the DataSource class
> and into the Transaction class...
> 

i'm trying to aim for a single interface that needs implementation here,
if possible...

> 
> We also need an iterator of some kind, so we can figure out the names in
> the data source, right?
> 
> I am assuming fully-qualified names throughout the code - we don't have
> add/remove zones, as to do that one would either add records of the
> appropriate name, or remove them all.
> 

err, yes, perhaps having non-fqdns and a zone context in which it
operates might be better, but atm we don't have non-fqdns yet :)


Jelte