LDAP-312: more flexibility for attribute mapping

[spring-projects-issues]

Brett Maxfield (Migrated from LDAP-312) said:

There seems be some things missing in the Spring-LDAP ODM annotations.

1. I'd like to mark an @Attribute as read-only, so it will populate the bean from LDAP for reference, but not persist it back to ldap. I'd suggest adding an attribute read-only to @Attribute, defaulting to false, for the usual case.
2. The default attributes of * misses all the operational attributes, some of which are very useful, and transfers more data than is required, slowing down the ldap query with attributes which will never be used.

An example of this; it would be very useful, for literally read only, such as entryUUID, etag, etc., which you cannot use if you wish to persist only some fields back to ldap, as the bean fails to persist to ldap with an exception when you save the bean. But also would be useful for general fields which you want to structurally prevent the user from ever updating.

You can get around this by not annotating read-only fields, and then manually populating the read only fields with a separate call. Very messy and kills the query speed.

Also on a related topic, query() could have a default list of attributes, which you have already annotated in your classes, something like :

public static String[] getBeanAttributes(Class<?> beanClass) {
ArrayList attrsObj = new ArrayList<>();
for (Field field : beanClass.getDeclaredFields()) {
if (field.isAnnotationPresent(Attribute.class)) {
Attribute attr = field.getAnnotation(Attribute.class);
attrsObj.add(attr.name());
}
}
String[] attrs = attrsObj.toArray(new String[attrsObj.size()]);
return attrs;
}

Above just returns a simple String[] of your declared attributes, to pass to query.attributes() - now i realize that as a static member, query() is built before the bean class is known, but at least there could be a helper function like the above, or a method signature for query attributes() that took a bean Class signature as an argument.

[spring-projects-issues]

David Lavender said:

Using AD LDS, the lockoutTime attribute is a good example of this.

I really want to display this value; so added it with an @Attribute(name = "lockoutTime"). It reads fine.

But now I can't save my object. I tried keeping value unchanged, setting value to null, zero, etc. But, as Brett says, AD throws errors every time.
These are computed fields in AD, so I guess I have no business even mentioning the attribute to AD, except for reading purposes.
I've tried various {@Transient annotations in different places, but no luck.

So some kind of readonly flag on @Attribute would be perfect.

[spring-projects-issues]

Brett Maxfield said:

My thoughts so far :

• add a boolean readOnly property to the @Attribute annotation (org.springframework.ldap.odm.annotations.Attribute)
• add the matching isReadOnly private variable (and matching getter) to AttributeMetaData, modifying processAttributeAnnotation() to populate the isReadOnly property

Then making mapToLdapDataEntry() in org.springframework.ldap.odm.core.impl.DefaultObjectDirectoryMapper() ignore ldap attributes where isReadOnly() is true

Above seems straight forward enough (and i've coded it - not too sure about how to be creating mock tests for it).

How do i go about contributing a prototype ?

[spring-projects-issues]

Brett Maxfield said:

first swing at coding attached (diff from master). a relatively simple simple change. but no tests done, needs some rigour

will look at some tests on the weekend.. but not yet familiar with how the ldap mocks work, exactly

[spring-projects-issues]

Brett Maxfield said:

Any ideas on how to inject the requested attributes[] into things such as query().attributes() based on the contents of AttributeMetaData from the odm interface would be welcome. The QueryBuilder seems an entirely separate interface.

Otherwise the default requested attributes is * (which excludes operational attributes) so @Attributes that happen to be operational will not be returned by default, as operational attributes need to be requested explicitly.

A workaround would be for users of query() to instantiate their own AttributeMetaData(TheClass.class) and call a convenience method to get attributes[] to request in their query().attributes() but it would be nice to default to the annotated @Atributes in the class, for several reasons (efficiency, non-defaulr operational attributes).

[spring-projects-issues]

Brett Maxfield said:

Revised with a getAttributes() convenience method

[spring-projects-issues]

don jones said:

an alternative would be to overload the LdapQueryBuilder's attributes method to take a class. Checks could be performed to validate that it is an @entity and reflection could be used to derive a String[] of attributes. Usage would look something like:

MyEntity myEntity =
        ldapTemplate.findOne(
            query()
                .base("ou=People")
                .attributes(MyEntity.class)
                .where("uid").is(uid), MyEntity.class);

This would preserve the default behavior that retrieves all attributes, but allow a simple way to only pull those attributes your interested in.

I sloppily implemented this to validate and it seems viable.

[kwin]

The patch being attached to https://jira.spring.io/browse/LDAP-312 does not correctly request only those attributes being found in the metadata in the methods

1. <T> T findByDn(Name dn, Class<T> clazz)
2. <T> T findOne(LdapQuery query, Class<T> clazz)
3. <T> List<T> find(LdapQuery query, Class<T> clazz)
4. <T> List<T> findAll(Class<T> clazz)
5. <T> List<T> findAll(Name base, SearchControls searchControls, Class<T> clazz)
6. <T> List<T> findAll(Name base, Filter filter, SearchControls searchControls, Class<T> clazz)

Only for method 2 & 3 it is currently possible to explicitly request some operational attributes by putting those into the query param.