OpenNeo/impress
OpenNeo/impress
1
0
Fork 1
Code Pull requests Activity
impress/app/flex/flex_search.yml

67 lines
1.5 KiB
YAML
Raw Normal View History

globalized search first draft Confirmed features: * Output (retrieval, sorting, etc.) * Name (positive and negative, but new behavior) * Flags (positive and negative) Planned features: * users:owns, user:wants Known issues: * Sets are broken * Don't render properly * Shouldn't actually be done as joined sets, anyway, since we actually want (set1_zone1 OR set1_zone2) AND (set2_zone1 OR set2_zone2), which will require breaking it into multiple terms queries. * Name has regressed: ignores phrases, doesn't require *all* words. While we're breaking sets into multiple queries, maybe we'll do something similar for name. In fact, we really kinda have to if we're gonna keep sorting by name, since "straw hat" returns all hats. Eww.
2013-01-18 21:23:37 -08:00
# Add here your search queries
# see the detailed Source documentation at https://github.com/ddnexus/flex/wiki/Sources
# ANCHORS litheral key: it will not be used as template
# you can store here fragments of queries to reuse in the templates below
ANCHORS:
species/zone conditions now render properly, instead of raising parse error from elastic
2013-01-21 10:33:26 -08:00
- &species_support_id_partial
term:
species_support_id: <<species_support_id>>
- &occupied_zone_id_partial
terms:
occupied_zone_id: <<occupied_zone_id>>
- &restricted_zone_id_partial
terms:
restricted_zone_id: <<restricted_zone_id>>
globalized search first draft Confirmed features: * Output (retrieval, sorting, etc.) * Name (positive and negative, but new behavior) * Flags (positive and negative) Planned features: * users:owns, user:wants Known issues: * Sets are broken * Don't render properly * Shouldn't actually be done as joined sets, anyway, since we actually want (set1_zone1 OR set1_zone2) AND (set2_zone1 OR set2_zone2), which will require breaking it into multiple terms queries. * Name has regressed: ignores phrases, doesn't require *all* words. While we're breaking sets into multiple queries, maybe we'll do something similar for name. In fact, we really kinda have to if we're gonna keep sorting by name, since "straw hat" returns all hats. Eww.
2013-01-18 21:23:37 -08:00
update item search to original name-matching behavior We originally had a regression on name-matching, where, among other issues, `straw hat` returned items containing both "straw" and "hat", which isn't really helpful behavior since we're sorting alphabetically. Now, `straw hat` behaves as expected. Additionally, "phrases like these" behave as expected, too.
2013-01-21 11:17:36 -08:00
_names:
multi_match:
query: <<name>>
fields: <<fields>>
type: phrase
globalized search first draft Confirmed features: * Output (retrieval, sorting, etc.) * Name (positive and negative, but new behavior) * Flags (positive and negative) Planned features: * users:owns, user:wants Known issues: * Sets are broken * Don't render properly * Shouldn't actually be done as joined sets, anyway, since we actually want (set1_zone1 OR set1_zone2) AND (set2_zone1 OR set2_zone2), which will require breaking it into multiple terms queries. * Name has regressed: ignores phrases, doesn't require *all* words. While we're breaking sets into multiple queries, maybe we'll do something similar for name. In fact, we really kinda have to if we're gonna keep sorting by name, since "straw hat" returns all hats. Eww.
2013-01-18 21:23:37 -08:00
update item search to original name-matching behavior We originally had a regression on name-matching, where, among other issues, `straw hat` returned items containing both "straw" and "hat", which isn't really helpful behavior since we're sorting alphabetically. Now, `straw hat` behaves as expected. Additionally, "phrases like these" behave as expected, too.
2013-01-21 11:17:36 -08:00
_negative_names:
multi_match:
query: <<name>>
fields: <<fields>>
type: phrase
globalized search first draft Confirmed features: * Output (retrieval, sorting, etc.) * Name (positive and negative, but new behavior) * Flags (positive and negative) Planned features: * users:owns, user:wants Known issues: * Sets are broken * Don't render properly * Shouldn't actually be done as joined sets, anyway, since we actually want (set1_zone1 OR set1_zone2) AND (set2_zone1 OR set2_zone2), which will require breaking it into multiple terms queries. * Name has regressed: ignores phrases, doesn't require *all* words. While we're breaking sets into multiple queries, maybe we'll do something similar for name. In fact, we really kinda have to if we're gonna keep sorting by name, since "straw hat" returns all hats. Eww.
2013-01-18 21:23:37 -08:00
species/zone conditions now render properly, instead of raising parse error from elastic
2013-01-21 10:33:26 -08:00
_species_support_ids:
*species_support_id_partial
_negative_species_support_ids:
*species_support_id_partial
_occupied_zone_ids:
*occupied_zone_id_partial
_negative_occupied_zone_ids:
*occupied_zone_id_partial
_restricted_zone_ids:
*restricted_zone_id_partial
_negative_restricted_zone_ids:
*restricted_zone_id_partial
globalized search first draft Confirmed features: * Output (retrieval, sorting, etc.) * Name (positive and negative, but new behavior) * Flags (positive and negative) Planned features: * users:owns, user:wants Known issues: * Sets are broken * Don't render properly * Shouldn't actually be done as joined sets, anyway, since we actually want (set1_zone1 OR set1_zone2) AND (set2_zone1 OR set2_zone2), which will require breaking it into multiple terms queries. * Name has regressed: ignores phrases, doesn't require *all* words. While we're breaking sets into multiple queries, maybe we'll do something similar for name. In fact, we really kinda have to if we're gonna keep sorting by name, since "straw hat" returns all hats. Eww.
2013-01-18 21:23:37 -08:00
item_search:
- query:
bool:
must:
- term:
is_nc: <<is_nc= ~>>
- term:
is_pb: <<is_pb= ~>>
update item search to original name-matching behavior We originally had a regression on name-matching, where, among other issues, `straw hat` returned items containing both "straw" and "hat", which isn't really helpful behavior since we're sorting alphabetically. Now, `straw hat` behaves as expected. Additionally, "phrases like these" behave as expected, too.
2013-01-21 11:17:36 -08:00
- <<_names= ~>>
species/zone conditions now render properly, instead of raising parse error from elastic
2013-01-21 10:33:26 -08:00
- <<_species_support_ids= ~>>
- <<_occupied_zone_ids= ~>>
- <<_restricted_zone_ids= ~>>
globalized search first draft Confirmed features: * Output (retrieval, sorting, etc.) * Name (positive and negative, but new behavior) * Flags (positive and negative) Planned features: * users:owns, user:wants Known issues: * Sets are broken * Don't render properly * Shouldn't actually be done as joined sets, anyway, since we actually want (set1_zone1 OR set1_zone2) AND (set2_zone1 OR set2_zone2), which will require breaking it into multiple terms queries. * Name has regressed: ignores phrases, doesn't require *all* words. While we're breaking sets into multiple queries, maybe we'll do something similar for name. In fact, we really kinda have to if we're gonna keep sorting by name, since "straw hat" returns all hats. Eww.
2013-01-18 21:23:37 -08:00
must_not:
update item search to original name-matching behavior We originally had a regression on name-matching, where, among other issues, `straw hat` returned items containing both "straw" and "hat", which isn't really helpful behavior since we're sorting alphabetically. Now, `straw hat` behaves as expected. Additionally, "phrases like these" behave as expected, too.
2013-01-21 11:17:36 -08:00
- <<_negative_names= ~>>
species/zone conditions now render properly, instead of raising parse error from elastic
2013-01-21 10:33:26 -08:00
- <<_negative_species_support_ids= ~>>
- <<_negative_occupied_zone_ids= ~>>
- <<_negative_restricted_zone_ids= ~>>
globalized search first draft Confirmed features: * Output (retrieval, sorting, etc.) * Name (positive and negative, but new behavior) * Flags (positive and negative) Planned features: * users:owns, user:wants Known issues: * Sets are broken * Don't render properly * Shouldn't actually be done as joined sets, anyway, since we actually want (set1_zone1 OR set1_zone2) AND (set2_zone1 OR set2_zone2), which will require breaking it into multiple terms queries. * Name has regressed: ignores phrases, doesn't require *all* words. While we're breaking sets into multiple queries, maybe we'll do something similar for name. In fact, we really kinda have to if we're gonna keep sorting by name, since "straw hat" returns all hats. Eww.
2013-01-18 21:23:37 -08:00
sort:
- name.<<locale>>.untouched
Copy permalink