Thanks for logging this, @therepanic. I think we should take some care when adding this feature.

First, there is an important difference between JdbcClient#MappedQuerySpec and LdapClient#SearchSpec that would be nice to reconcile at this point.

In JdbcClient we have:

statement().query(query).single() // requires one result
statement().query(query).optional() // allows result to be null

And in LdapClient we have:

search().query(query).toEntry() // allows result to be null

It would be nice to be able to do:

search().query(query).single() // requires one result
search().query(query).optional() // allows result to be null

to align with JdbcClient semantics and naming convention.

I would propose, then, making the following changes:

Add single, optional, list, and stream, deprecating toEntry, toObject, toList, and toStream
Add map(ContextMapper) and map(AttributeMapper) methods that return a new interface (say, MappedSearchSpec) that also has single, optional, list, and stream.

This separates mapping operations from cardinality terminal methods:

search().query(query).single() // requires one LdapDataEntry result
search().query(query).map(contextMapper).single() // requires one result, mapped by ContextMapper
search().query(query).map(attributeMapper).single() // requires one result, mapped by AttributeMapper

This would change the call referenced in the related Spring Security PR to:

ldapClient.search().query(query).single();

and remove the check for null.

Are you able to provide a PR along these lines? Note that any new methods in SearchSpec need to have default implementations in order to preserve backward compatibility.

Add support for mandatory single result in LdapClient search operations #1404

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Add support for mandatory single result in `LdapClient` search operations #1404