BIND 10 #1068: support writability in the new data source API

[BIND 10 Development]

#1068: support writability in the new data source API
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110830
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  7.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:8 jinmei]:
 > >  * The order of columns is different in the read and write methods
 (eg. the name is at the end in reading, at the beginning when writing).
 Wouldn't it be cleaner if they had the same order (with obvious variations
 around columns present only at one method)? They can be freely reordered
 in the SQL command, so it shouldn't be a technical problem.
 >
 > Considering these, I'd be slightly inclined to keep this unchanged
 > (and let them "inconsistent").  But if you still prefer inconsistency
 > after taking into account these points and have a specific proposed
 > ordering, I'm okay with adopting it.

 It's not important, no problem in keeping them. I thought it might be just
 overlooked, but if there's a reason for it, it's OK.

 > >  * To make the interface consistent, should the vectors be replaced by
 fixed-sized arrays and their sizes be checked compile-time by the
 reference trick?
 >
 > Another good point.  I actually considered that option, but didn't
 > choose it because I wanted to share the doUpdate() code for both
 > of the add/delete cases (they have different sizes of columns/params).
 > But on thinking it further, it wouldn't be a good idea to make the
 > public interface counter-intuitive due to the convenience of internal
 > implementation, and, in fact I found it not so difficult to share the
 > update code for both cases using C++ template.  So I made the change.

 Yes, nice. Well, it could be done with `std::string param[]` (which would
 take whatever length of array), but it doesn't matter.

 > >  * There are enums used as indices and with the last _COUNT item to
 mark the count. On one side, we have a requirement to manually number
 enums in our style guide (I think I saw it somewhere), but maybe in this
 and similar cases, we should reconsider. The standard says an enum starts
 at 0 and each next item is one larger than previous, if the number is
 free, which is exactly what we want in this case (numbering by one,
 starting at 0). Numbering manually is error prone, since human might just
 add one and not update all the previous ones, or something. Should we
 discuss it on the ML?
 >
 > [...]
 >
 > So, I'm not sure which one is better.  And yes, we should probably
 > discuss it on the ML.

 ACK, I'll send an email.

 > >  * Isn't the agent for execution called „executioner“ instead of
 „executer“ (sorry, I'm not native speaker, but I did not hear the second).
 >
 > As you know I'm not a native English user either:-) I've looked up
 > dictionaries and, you're right, there's no "executer".  I simply named
 > it so by naive convention of adding "-er", and I have no problem with
 > using a real word.  But "executioner" doesn't seem to be the right
 > choice either because the only meaning (as far as I know, and
 > according to the dictionaries I have) of it is "a person who has the
 > job of executing criminals."

 Well, maybe the dictionary has execute only as cut off someone's head. But
 I admit the executioner probably isn't usually used as something that
 executes code (although executing code is repeatedly removing the head of
 the code and doing something with it) and this use would be somewhere on
 borderline with language joke.

 The StatementProcessor is probably slightly better, but anything is OK if
 the reader can guess what it does. I just noted the word looked odd to me.

 > >  * Is it guaranteed that the application will see the updated data in
 the transaction, or is it implementation detail of the SQLite one? Is it
 allowed for some backend to create a separate connection for the updates
 and have any reads out of that transaction? Do we support DBs that don't
 support transactions (eg. text files, CVS files, some tables of MySQL)?
 >
 > As commented above, the idea is to guarantee that by the use of
 > "update finder", assuming the underlying database supports
 > transactions.

 ACK, I just asked.

 It can be merged (or considered done), with or without the renaming, as
 you like.

 With regards

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