feat(java): browse objects/synonyms/rules

[millotp]

🧭 What and Why

🎟 JIRA Ticket: APIC-616

Implement browse for object/synonyms/rules.

They are meant to be used with for loop like:

Iterable<Actor> browse = client.browseObjects(indexName, new BrowseParamsObject(), Actor.class);
for(Actor actor : browse) {
  System.out.println(actor.name);
}

Changes included:

• Not sure if the doc is outdated or the query was wrong but _highlightResult only contains "synonym" and never the expected object, so we decided to remove it from the spec.
• Move the helpers to it's own mustache file

🧪 Test

Playground with the snippet above

[netlify]

✅ Deploy Preview for api-clients-automation canceled.

Name	Link
🔨 Latest commit	11a306e
🔍 Latest deploy log	https://app.netlify.com/sites/api-clients-automation/deploys/6307879fd770d70008022f83

[algolia-bot]

✗ The generated branch has been deleted.

If the PR has been merged, you can check the generated code on the main branch.
You can still access the code generated on main via this commit.

[shortcuts]

shouldn't it still be there but a string?

[millotp]

I'm afraid in some case it can be the object, as defined here and in that case it would be a mess.
I'm not sure what's best

[shortcuts]

Maybe worth to go with what we know for now and assume that it can be an enum "synonym" or a free form object?

It should be enough until we have a proper use case to investigate, wdyt?

[shortcuts]

Would it still be valid once the Java unknown parameter validation is removed?

[millotp]

FAIL_ON_UNKNOWN_PROPERTIES is already disabled for the client, but it will still fail when trying to deserialize a known property, maybe I could return null instead of throwing but then it's misleading.
Are you sure this property is ever used for synonym ?

[millotp]

for rules we have the same issue, it's listed in the doc but not in our spec

[shortcuts]

In the JS client, browseRules and browseSynonyms both delete the _highlightResult key for each responses, but not in the searchRules and searchSynonyms methods. I'd be fine keeping the same logic until we have some context

maybe @Haroenv (off) @francoischalifour (?) knows more about those?

[francoischalifour]

I don't know, but I would guess that we prefer having consistent keys when using search endpoints to facilitate the data flow in the consumers.

[millotp]

from usage it seems like _highlightResult is pretty random (example) so we remove it for now

[shortcuts]

adding this here for future reference of motivations:

• Add quick check to PaginatorIterator to check if the hits dictionary … algoliasearch-client-python#545
• https://github.com/algolia/algoliasearch-client-javascript/blob/master/packages/client-search/src/methods/index/browseRules.ts#L32
• https://github.com/algolia/algoliasearch-client-javascript/blob/master/packages/client-search/src/methods/index/browseSynonyms.ts#L32

[shortcuts]

good!