Looks good. The only downside I can see with this approach is that when we read a resource, we won't automatically get the resource constraints (and likewise for other models) since constraints wouldn't be attributes. Or am I misunderstanding?
Kanak ---------------------------------------- > Date: Sat, 22 Mar 2014 23:19:34 -0700 > Subject: Re: Update: New Helix API's > From: [email protected] > To: [email protected] > > Hey guys, > > I created a package model.constraint and moved the ClusterConstraint, > ConstraintItem, ConstraintItemBuilder in there. I moved ConstraintId > into model.id since I did not think it was necessary to create a > package model.constraint.id for one class. > > I also moved ExternalView into model.composite since the way I > understand it, it is a composite view across the cluster. > > All these are subject to discussion and realignment as we go forward > but wanted to make sure we get all the elements in api in the relevant > packages so we have all the necessary items on the table so we can > work to cleanup and moving towards the apis like Helix-Admin. > > Everything is checked in, it builds. Comments/feedback are welcome. > > Thanks, > > Sandeep > > On Sat, Mar 22, 2014 at 10:26 PM, Sandeep Nayak <[email protected]> wrote: >> I am leaning towards #1 it would be cleaner to apply constraints on >> the model elements and keep those constraints separated so we can >> evolve them independently. >> >> Sandeep >> >> On Sat, Mar 22, 2014 at 2:09 PM, kishore g <[email protected]> wrote: >>> Hi, >>> >>> Thanks to Sandeep and Kanak we are getting close to having the new >>> helix-api package. >>> >>> https://github.com/kanakb/helix >>> >>> Here is the api package >>> https://github.com/kanakb/helix/tree/master/helix-api/src/main/java/org/apache/helix/api >>> >>> Feedback/suggestions? >>> >>> >>> Before we get started working on the roles (administrator, participant, >>> controller, spectator), we need to wrap up the constraints api. >>> >>> At a high level we have state & transition constraints at cluster, >>> participant, resource, partition granularity. >>> >>> We have two options >>> >>> #1 Have a separate package called constraints and have >>> (cluster|participant|resource|partition)Constraint. >>> >>> #2. Have StateConstraint & TransitionConstraint as attributes in >>> (cluster|participant|resource|partition)configuration. >>> >>> Thoughts. >>> >>> >>> thanks, >>> Kishore G
