Mailing-List: contact dev-help@nifi.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@nifi.apache.org
From: mcgilman <git@git.apache.org>
To: dev@nifi.apache.org
Reply-To: dev@nifi.apache.org
References: <git-pr-452-nifi@git.apache.org>
In-Reply-To: <git-pr-452-nifi@git.apache.org>
Subject: [GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...
Content-Type: text/plain
Message-Id: <20160519121750.47B60DFBD6@git1-us-west.apache.org>
Date: Thu, 19 May 2016 12:17:50 +0000 (UTC)
archived-at: Thu, 19 May 2016 12:17:52 -0000

Github user mcgilman commented on the pull request:

    https://github.com/apache/nifi/pull/452#issuecomment-220307255
  
    @alopresto Thanks for the very thorough review! This API is designed strictly for handling the persistence of access policies which would also include Users and Groups. These objects are designed as simple data objects or POJOs. While the MutableAuthorizer can load these records, it must be told when to save. It wouldn't know a given User/Group/Policy has been modified. This is part of the motivation to have the objects be immutable. The intent is very clear to an implementor of MutableAuthorizer that the objects won't be modified outside of their knowing. I believe that @bbende recommendation of introducing a Builder for creating new versions of a given User/Group/Policy is a great way to handle the cloning.
    
    The end goal here was to design the API such that the implementation only needed to be concerned with persistence.
    
    **uniqueness constraint** - How we address this would ultimately be based on whether we support reloading the Users/Groups/Policies while the application is running. We decided against this as the motivation for the MutableAuthorizer API was to support an Authorizer that was managed by NiFi. With this approach we would be enforcing uniqueness at startup and when new records were added outside of the MutableAuthorizer.
    
    **ID mutability** - The identifier of a record is not mutable. The identity of a user and name of a group are (using the clone/builder approach described). This is to more easily support name chanes or typos without having to re-create all the policies for that entity as well.
    
    **locks & merge conflicts** - Thread locking is handled by the web tier using the same mechanism as the other Resources. For 1.0.0 we are introducing fine grain locking through a RevisionManager. Obtaining a write lock for a given record would require a client to include a Revision. The RevisionManager manager would validate the Revision and lock the Revision to prevent other clients from modifying the same record.
    

---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---