Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support of multiple conditions for term aggregation order #1478

Closed
cjost1988 opened this issue Apr 5, 2018 · 5 comments
Closed

Support of multiple conditions for term aggregation order #1478

cjost1988 opened this issue Apr 5, 2018 · 5 comments

Comments

@cjost1988
Copy link
Contributor

Hello,

I figured out that elasticsearch is allowing multiple conditions for term aggregation orders.
But as far as I understand Aggregation\Terms::setOrder() is not capable of this feature.

Are there any plans to support this?

Cheers,
Christian

@ruflin
Copy link
Owner

ruflin commented Apr 6, 2018

You are right that there is not a named API function for this today but you can already make use of it by using setParam on your Terms object. All setOrder does is using setParam and setting one array:

return $this->setParam('order', [$order => $direction]);

On your end you can pass an array with your values:

$terms->setParam('order', [$order1 => $direction1, $order2 => $direction2]);

I haven't tested it but that should work.

Interested to contribute a setOrders or addOrder method?

@cjost1988
Copy link
Contributor Author

cjost1988 commented Apr 6, 2018

@ruflin Thank you for your quick response.

Yes, I already forked your repo and added these methods on my own :) I didn't wanted to call the setParam/addParam methods directly to keep it clean.

I'll add tests and will provide a PR when it's ready from my side.

@cjost1988
Copy link
Contributor Author

I'll add an additional method setOrders beside setOrder which takes an array of order definitions to not add a BC => could be merged without adding BC release.

This also guarantees no broken queries if a user will execute both setOrder and setOrders at the same time. Just overwriting his previous definition.
An addOrder beside the current setOrder method could potentially lead to wrong queries.

@ruflin
Copy link
Owner

ruflin commented Apr 6, 2018

SGTM. Looking forward to the PR.

Let's skip addOrder until we see a use case for it.

@cjost1988
Copy link
Contributor Author

This got resolved in: #1480

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants