I’m testing delivery tier queries in my back-end Java code, and I’m trying to understand why one query works for me but another doesn’t. I have a guess for this, but I’m hoping that someone might confirm it for me.
Here’s what works and returns results:
HstQueryBuilder.create( JcrUtils.getNodeIfExists("/content/documents", session)) .ofTypes("myproject:contentdocument") .build(queryManager).execute().getHippoBeans(); // It works!
Please don’t mind the fact that I’m using JcrUtils - I’m working outside of the HstRequestContext, following the search bootstrapping advice presented under: https://documentation.bloomreach.com/library/concepts/fluent-search/fluent-hstquerybuilder-bootstrapping.html
At any rate, the above query works and returns the expected search results from the tree rooted under “/content/documents”. That’s great.
However, I wanted to experiment with searching for users, due to a feature I’m working on. Users are not defined under “/content/**” naturally. They’re under “/hippo:configuration/hippo:users” and their node primary types are “hipposys:user” as can be clearly seen by browsing existing users in cms/console.
I came up therefore with the following query, but no objects get returned:
HstQueryBuilder.create( JcrUtils.getNodeIfExists("/hippo:configuration/hippo:users", session)) .ofTypes("hipposys:user") .build(queryManager).execute().getHippoBeans(); // No results...
I believe the reason why the former returns objects is because, in my project code, I have a ContentDocument.java bean there with the “public class …” line annotated as follows:
@Node(jcrType = "myproject:contentdocument")
There is no corresponding ‘@Node(jcrType = “hipposys:user”)’ annotation anywhere in the platform for Users. Hence, they are not searchable, even though they exist in the repository.
Is my guess above correct?
If it’s correct, is there a way for someone to define a JCR node-annoted class for JCR repository objects like Users so that they can be searched?
Admittedly, I’m doing the above because I want to eventually link Bloomreach User accounts with additional information: eg., find a way to add additional fields to the User type (eg. say, “erpId”), link each user to a new Address type so that users may have addresses, etc. As you might imagine, some of this will matter for eCommerce, CRM, or related needs.
However, my thinking in (3), above, may not be ideal in Bloomreach: Maybe User objects in BR were designed to be relatively static in type/properties and, if I really need to add more information related to users, I should define a new Document type for users (eg. UserDocument). And perhaps assume a one-to-one association via User.username == UserDocument.username.
If anyone might be willing to share their opinions/design approaches to extending User data and searching for it, it would be very much appreciated!
As always, many thanks to the fine Bloomreach community!