We already have some support of “object IDs” at the mapper level (see @IndexedEmbedded#includeEmbeddedObjectId), so this would mostly involve formalizing the concept at the backend level (allowing to declare “id fields” or marking one field of an object as an “id”). Then we could allow this in the predicate/projection DSL: f.id("path.to.myobjectfield") or f.id().field("path.to.myobjectfield"). And finally, we should be able to take advantage of those DSLs in the IdProjectionBinder to project on object IDs.
There is one alternative: define a completely separate predicate/projection for object IDs. But that doesn’t play well with composition of projection constructors: in the example above, one would need to have two separate definitions of AuthorDTO: one for inclusion in BookDTO}}when querying the {{book index, using @ObjectIdProjection, and for top-level use when querying the author index, using @IdProjection. That’s a shame when we already allow advanced composition using @ObjectProjection(includeDepth/includePaths/excludePaths). Maybe @ObjectIdProjection would make sense if we also introduced something like @RootOrObjectIdProjection, but this feels really clumsy… |
