Sounds good to me. Couple of things.
HelixRecord, HelixKey, HelixValue looks good. Not sure if we need Helix prefix every where. will user access Record, key, value directly. This is probably needed only for the spi implementation. similarly dataaccessor will only be of interest to spi. Users will only use model classes and helixadmin for CRUD. Should we differentiate what is exposed to user v/s spi implementation. ResourceConfig is too complex, do we need to break it down? thanks, Kishore G On Mon, Mar 3, 2014 at 1:21 AM, Sandeep Nayak <[email protected]> wrote: > Hi guys, > > There have not been any code changes since the last update on > 03-01-2014 however there was some discussion on the design of the > Helix API today which is summarized below > > Participants: Kishore, Kanak and myself. > > Kishore and Kanak please correct me if I misrepresented any of the > discussion. > > (1) HelixProperty will be renamed to HelixRecord which will > internally have HelixKey and HelixValue. > > (2) HelixKey is what is currently PropertyKey in Helix. A key is not > versioned. A key is a path to the value stored. There was much > discussion on trying to surface the segmented nature of the key in the > API by expressing it as a URN but was tabled to be revisited later. > > (3) HelixValue is a value the key points to and is currently ZNRecord. > A value is versioned and each key points to the latest value. The > version helps build a CAS (CompareAndSet) semantic for update calls. > > (4) Helix Record will be placed in the model package along with > HelixKey and HelixValue > > (5) Model package will carry classes with accessors only, all > mutations should go through commands for the same. There is concern > that we may end up proliferating commands so we need to be cognizant > of this when we build the commands. > > (6) Command builders will be put in place to allow creating the commands > > (7) There was much discussion on the nomenclature of Instance v/s > (Participant, Observer or Admin) in Helix. The conclusion was to avoid > using Instance in the API as it is confusing and was legacy. Instead > we will use the specific terms of Participant, Observer, Admin in > command objects. For the sake of completion, a Node is seen as a > physical instance which is why the abstraction of a Node was avoided. > > (8) Another example of command is ResourceCommand, it will have to > carry the resource configuration and will need some way to express the > Rebalancer config. So a command like > ResourceCommand.using(ResourceConfig).with(RebalancerConfig) maybe. > More details to be discussed as we move closer to the command design. > > (9) The HelixAdmin is thus shaping to have an API like > > newValue = HelixAdmin.do(Command) or > newValue = HelixAdmin.execute(Command). > > The call internally reads existing data from the persistent store, > identifies the deltas to be applied based on the command issued and > applies the deltas to the store through the data accessor. The return > value is the new model value. > > (10) This leads to ZNRecordDelta not being necessary in the API > > Based on the above next things I plan to tackle in order are > > (a) the HelixProperty realignment as outlined in (1) above > (b) reworking some objects from config into model (see email exchange > for API rework summary 03-01-2014 thread) > (c) move more models into API, cleanup as necessary > (d) start on command objects > > I will send a summary as and when I tackle these and check-in code. > > > Thanks, > > Sandeep >
