Any plans to support faceting? #5
Comments
|
Can you please send questions to the mailing list? This is not a feature request format, its a question that might lead to a discussion which will end up as a feature request. ES has basic support for facet queries, other types of faces are on the road map. |
|
Sure, I'll use the mailing list for this kind of thing in the future. Thanks for the replies. |
|
Sure, no problem. To be honest, I don't know where best to conduct this. I now see that others actually maintain a mini forums in the issues, I am simply used to mailing lists to have discussions, and issue trackers to have discussions about open bugs or features implementations. But, maybe I am wrong, and this is a better place, what do you think? |
|
Closing for now. Will create issues for each new facet support that I plan. |
kimchy
added a commit
that referenced
this issue
Jun 5, 2015
dadoonet
added a commit
that referenced
this issue
Jun 5, 2015
Due to refactoring in 0.21.x we have to update this plugin Closes #5.
dadoonet
added a commit
that referenced
this issue
Jun 5, 2015
dadoonet
added a commit
that referenced
this issue
Jun 5, 2015
dadoonet
added a commit
that referenced
this issue
Jun 5, 2015
dadoonet
added a commit
that referenced
this issue
Jun 5, 2015
… the README.md In the `readme.md` file, `azure vm list` command should be changed to `azure vm image list`. The former lists all the VMs running in the current Azure subscription and the latter displays list of official available images. The line is located just below the following line: `To get a list of official available images, run:` Closes #5.
dadoonet
added a commit
that referenced
this issue
Jun 9, 2015
abeyad
pushed a commit
to abeyad/elasticsearch
that referenced
this issue
Nov 10, 2016
index-* blobs are generational files that maintain the snapshots in the repository. To write these atomically, we first write a `pending-index-*` blob, then move it to `index-*`, which also deletes `pending-index-*` in case its not a file-system level move (e.g. S3 repositories) . For example, to write the 5th generation of the index blob for the repository, we would first write the bytes to `pending-index-5` and then move `pending-index-5` to `index-5`. It is possible that we fail after writing `pending-index-5`, but before moving it to `index-5` or deleting `pending-index-5`. In this case, we will have a dangling `pending-index-5` blob laying around. Since snapshot elastic#5 would have failed, the next snapshot assumes a generation number of 5, so it tries to write to `index-5`, which first tries to write to `pending-index-5` before moving the blob to `index-5`. Since `pending-index-5` is leftover from the previous failure, the snapshot fails as it cannot overwrite this blob. This commit solves the problem by first, adding a UUID to the `pending-index-*` blobs, and secondly, strengthen the logic around failure to write the `index-*` generational blob to ensure pending files are deleted on cleanup. Closes elastic#21462
abeyad
pushed a commit
that referenced
this issue
Nov 11, 2016
…otting (#21469) Ensures pending index-* blobs are deleted when snapshotting. The index-* blobs are generational files that maintain the snapshots in the repository. To write these atomically, we first write a `pending-index-*` blob, then move it to `index-*`, which also deletes `pending-index-*` in case its not a file-system level move (e.g. S3 repositories) . For example, to write the 5th generation of the index blob for the repository, we would first write the bytes to `pending-index-5` and then move `pending-index-5` to `index-5`. It is possible that we fail after writing `pending-index-5`, but before moving it to `index-5` or deleting `pending-index-5`. In this case, we will have a dangling `pending-index-5` blob laying around. Since snapshot #5 would have failed, the next snapshot assumes a generation number of 5, so it tries to write to `index-5`, which first tries to write to `pending-index-5` before moving the blob to `index-5`. Since `pending-index-5` is leftover from the previous failure, the snapshot fails as it cannot overwrite this blob. This commit solves the problem by first, adding a UUID to the `pending-index-*` blobs, and secondly, strengthen the logic around failure to write the `index-*` generational blob to ensure pending files are deleted on cleanup. Closes #21462
abeyad
pushed a commit
that referenced
this issue
Nov 11, 2016
…otting (#21469) Ensures pending index-* blobs are deleted when snapshotting. The index-* blobs are generational files that maintain the snapshots in the repository. To write these atomically, we first write a `pending-index-*` blob, then move it to `index-*`, which also deletes `pending-index-*` in case its not a file-system level move (e.g. S3 repositories) . For example, to write the 5th generation of the index blob for the repository, we would first write the bytes to `pending-index-5` and then move `pending-index-5` to `index-5`. It is possible that we fail after writing `pending-index-5`, but before moving it to `index-5` or deleting `pending-index-5`. In this case, we will have a dangling `pending-index-5` blob laying around. Since snapshot #5 would have failed, the next snapshot assumes a generation number of 5, so it tries to write to `index-5`, which first tries to write to `pending-index-5` before moving the blob to `index-5`. Since `pending-index-5` is leftover from the previous failure, the snapshot fails as it cannot overwrite this blob. This commit solves the problem by first, adding a UUID to the `pending-index-*` blobs, and secondly, strengthen the logic around failure to write the `index-*` generational blob to ensure pending files are deleted on cleanup. Closes #21462
abeyad
pushed a commit
that referenced
this issue
Nov 11, 2016
…otting (#21469) Ensures pending index-* blobs are deleted when snapshotting. The index-* blobs are generational files that maintain the snapshots in the repository. To write these atomically, we first write a `pending-index-*` blob, then move it to `index-*`, which also deletes `pending-index-*` in case its not a file-system level move (e.g. S3 repositories) . For example, to write the 5th generation of the index blob for the repository, we would first write the bytes to `pending-index-5` and then move `pending-index-5` to `index-5`. It is possible that we fail after writing `pending-index-5`, but before moving it to `index-5` or deleting `pending-index-5`. In this case, we will have a dangling `pending-index-5` blob laying around. Since snapshot #5 would have failed, the next snapshot assumes a generation number of 5, so it tries to write to `index-5`, which first tries to write to `pending-index-5` before moving the blob to `index-5`. Since `pending-index-5` is leftover from the previous failure, the snapshot fails as it cannot overwrite this blob. This commit solves the problem by first, adding a UUID to the `pending-index-*` blobs, and secondly, strengthen the logic around failure to write the `index-*` generational blob to ensure pending files are deleted on cleanup. Closes #21462
This was referenced Nov 28, 2016
rahulanishetty
referenced
this issue
in rahulanishetty/elasticsearch
Jan 11, 2017
support for es5 query changes for filtered, missing, nested, query fi…
ywelsch
pushed a commit
to ywelsch/elasticsearch
that referenced
this issue
Dec 7, 2017
jasontedor
added a commit
to jasontedor/elasticsearch
that referenced
this issue
Jan 31, 2018
Today a SecureSM security manager allows defining a list of packages that can exit the VM. However, today there are no restrictions on defining a package inside another JAR. This commit strengthens the ability to prevent exit by allowing construction of SecureSM to be done with a list of regular expressions (instead of a list of prefix names) that classes will be tested against. With this, a security manager can be installed that permits only exiting from an exact list of classes. Relates elastic#5
jasontedor
added a commit
that referenced
this issue
Jan 31, 2018
Today a SecureSM security manager allows defining a list of packages that can exit the VM. However, today there are no restrictions on defining a package inside another JAR. This commit strengthens the ability to prevent exit by allowing construction of SecureSM to be done with a list of regular expressions (instead of a list of prefix names) that classes will be tested against. With this, a security manager can be installed that permits only exiting from an exact list of classes. Relates #5
vladimirdolzhenko
pushed a commit
to vladimirdolzhenko/elasticsearch
that referenced
this issue
May 4, 2018
… fixes on PR elastic#5 Relates to elastic#10708
ClaudioMFreitas
pushed a commit
to ClaudioMFreitas/elasticsearch-1
that referenced
this issue
Nov 12, 2019
…o elasticsearch server. Closes elastic#5
ClaudioMFreitas
pushed a commit
to ClaudioMFreitas/elasticsearch-1
that referenced
this issue
Nov 12, 2019
…o elasticsearch server. Closes elastic#5
henningandersen
referenced
this issue
in henningandersen/elasticsearch
Jun 4, 2020
Improve bulk indexing performance
carlosdelest
referenced
this issue
in carlosdelest/elasticsearch
Apr 28, 2023
Template parameters validation
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
One of the most useful features of Solr is faced searching - is that likely to be added to elasticsearch at any point?
The text was updated successfully, but these errors were encountered: