directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Pike <clp...@psu.edu>
Subject Re: Fortress Properties
Date Thu, 13 Oct 2016 14:56:15 GMT
I think that will work, but I don't see a way to search by user properties, so I still think
we need to decide how to expose searching through the API.



----- Original Message -----
From: "Steve Moyer" <smoyer@psu.edu>
To: fortress@directory.apache.org
Sent: Thursday, October 13, 2016 10:39:56 AM
Subject: Re: Fortress Properties

FPS is using the ftProps attribute to store data that isn't in the standard inetOrgPerson,
eduPerson or PSUPerson schemas.  We probably should have created a schema for some of it but
it's working well so far.  Note that these are all added to inetOrgPerson (or User via the
Fortress library).

Steve

“Object-oriented programming is an exceptionally bad idea which could only have originated
in California.” – Edsger Dijkstra

----- Original Message -----
From: "Shawn McKinney" <smckinney@apache.org>
To: fortress@directory.apache.org
Sent: Thursday, October 13, 2016 10:32:57 AM
Subject: Re: Fortress Properties

for now let’s keep it simple.  Follow the way it’s done in User which is probably the
closest to your target and has prop support already in add/update.

Next we can add an interface for DAO’s that have need…

public interface Properator  (just kidding on name:)
{

  FortEntity add ( FortEntity, String name, String value) throws Property Exception;
  FortEntity update ( FortEntity, String name, String value) throws Property Exception;
  void delete ( FortEntity, String name) throws Property Exception;
  String get ( FortEntity, String name) throws Property Exception;
  List<FortEntity>search ( FortEntity, String name, String value) throws Property Exception;
}

not all apis need to be supported on every entity nor will they need to be exposed publically.

Will that work?  If so, let’s create a ticket and get this info in there.  We can do this
work gradually as needed.  

Thanks,
Shawn

> On Oct 13, 2016, at 9:13 AM, Chris Pike <clp207@psu.edu> wrote:
> 
> That sounds like exactly what we want. We would want to add properties and have the ability
to generically filter by them, but don't need the API to act on them in any way.
> 
> I guess the question is what is the proper way to update the API to support this, for
example, to add to AdminRole
> 
> 1. Add properties field into object
>  - private Props props = new Props();
> 
> 2. Update DAO to insert / update / delete properties
> 
> 3. Add additional method to allow filtering by properties?
>  - public List<AdminRole> findRoles(String searchVal, List<Props.Entry> propFilters)
> 
> or more generic?
>  - List<FortEntity> searchEntity(List<Props.Entry> propFilters, Class targetClazz)
> 
> or change pattern of searching to more of a query builder?
>  - AdminRoleQuery query = AdminRoleQueryBuilder.addNameFilter("name").addPropertyFilter("key1",
"value").addPropertyFilter("key2", "value")
>  - public List<AdminRole> runAdminRoleQuery(AdminRoleqQuery query)
> 
> 
> 
> 
> ----- Original Message -----
> From: "Shawn McKinney" <smckinney@apache.org>
> To: fortress@directory.apache.org
> Sent: Thursday, October 13, 2016 8:46:04 AM
> Subject: Re: Fortress Properties
> 
>> On Oct 12, 2016, at 9:27 PM, Chris Pike <clp207@psu.edu> wrote:
>> 
>> I noticed that all of the fortress entities have the ftProperties object class in
LDAP, which means that they can all contain many ftProps. Is that correct? Are the ftProps
meant to be user defined defined properties? If so, does the API provide any mechanism to
set or query by these properties?
> 
> The props aux obj class:
> ## AC2: Fortress Properties Auxiliary Object Class
> objectclass ( ftAxId:2
>    NAME 'ftProperties'
>    DESC 'Fortress Properties AUX Object Class'
>    AUXILIARY
>    MAY (
>        ftProps
>        )
>    )
> 
> Is allowed on AdminRole, Config, PermObj, PermOp, Role and User entities.  
> 
> But there is only code written on Config, PermObj and Users which allow some level of
adding and updating props.  No APIs for search at the moment - except for Config which of
course is just an entity containing properties.  
> 
> I would be in support of expanding the usage of properties as long as there aren’t
business rules associated with it.  For example it would be fine to have apis to perform generic
searches on property names / values
> 
> List<FortEntity> searchEntity(propName, PropValue
> 
> I would also support adding code to implement the property capability on the other entities,
both those listed above and those not.
> 
> For me the general idea of a property is that we offer apis for CRUD but don’t interpret
the value of a property on behalf of the caller.  That is the caller pulls it back and it
is up to it to decide what to do with it.
> 
> Shawn

Mime
View raw message