Roadmap 3.0

[erichard]

I've started a full rewrite with better terminology and wider elastic support.

It will also include test and documentation.

Check the UPGRADE.md for more information

Features

• Query/Filter
  • Boolean
  • GeoDistance
  • GeoBoundingBox (thanks to @pionl)
  • GeoShape (thanks to @jaetooledev)
  • MatchPhrasePrefix
  • MatchPhrase
  • Match
  • MultiMatch
  • Nested
  • Prefix
  • Range
  • Term
  • Terms
  • Wildcard
  • Exists (thanks to @wucdbm )
  • QueryString
• Aggregation
  • Filter
  • Max
  • Min
  • Nested
  • Reverse
  • Terms
  • TopHits
  • Cardinality
  • DateHistogram
  • Histogram (thanks to @pionl)
  • Range (thanks to @pionl)
  • Stat (thanks to @pionl)
  • Sum
  • WidthHistogram (thanks to @pionl)

[wucdbm]

Hey,

Nice work, thank you very much for the library.

I just started using ~v2 and hit a brick wall assuming I could add multiple Filter instances to the query builder, but then noticed this line in QueryBuilder $query['body']['query'] = $filter->build();
Just not the best DX for a novice in Elastic, but hey.

How much work do you think v3 still needs before rolling out? Is there anything I could help with?

PS Not very experienced with Elastic

[erichard]

Hi,

You cannot have multiples queries in Elastic Search, that why the filter build is only done one time.
To use multiple filters you need a Boolean Query : https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-bool-query.html. In v2 you can you use Filter::bool() to create one.

I use v3 in production already but I want a better feature coverage before taggind a stable version.

[wucdbm]

Fair enough, I'm also already using it, will be in production in a month or two.

@query, noticed that after reverting back to the documentation of Elastic again.

New API seems decent, are all query classes supposed to have a constructor with nullable arguments, as well as creatable through the Query factory class?

[erichard]

I'm not sure about the design of the constructor yet. What I'm trying to acheive is to avoid the extras checks in build(), for that we need to make sure all required properties are setted at constructor level.

[wucdbm]

Hm, alright. Then maybe we could make the constructors require all possible arguments, make them private, and create named constructors that describe what you'd like to create. Then keep the setters ofc, as you would want to keep adding filters etc to a BoolQuery for example.

On the other hand, that may not be possible for BoolQuery where you could have arbitrary filters applied, possibly zero, and you still have to do if (!$query->isEmpty()) before setting it @ QueryBuilder

Another approach I can think of is doing an internal check in QueryBuilder, whether a Query is empty. If it is, do pretend it wasn't set at all. This will allow getting rid of those checks altogether, enforcing most queries to require all of their args @ constructor, and for BoolQuery, that would be somewhat special, allowing you to construct it with empty lists.

if (null !== $this->query && !$this->query->isEmpty()) {
            $query['body']['query'] = $this->query->build();
        }

WDYT?

[byt3sage]

@erichard in V3, Query is has functions such as match() which returns a new MatchQuery without constructor arguments. I presume that either these need updating to pass in the arguments (like the term() and terms() function) or, the constructors need removing.

I'd like to go ahead and update all of the query classes so that they can be used both match('testField', 'testvalue') and match()->setField('testField')->setValue('testvalue').

If this is okay I'll crack on and get that change PR'd

[erichard]

So we need to make a decision here. I have postponed this enough 😄

The main goal is to avoid building invalid query. We can do that either by asserting things in the build () methods or by ensuring we cannot build an invalid object. V2 use the first method and the idea of V3 is to get rid of assertion in build().

Besides I think it's a better DX to use a library that prevent you to do bad things.

So from now:

• Every QueryInterface MUST have a constructor with all arguments needed to build a valid query
• All others arguments MUST have a setter.

@jaetooledev If you are up to the task, feel free to rock the place 👍

[byt3sage]

@erichard is there any other easy wins outstanding?

[erichard]

@jaetooledev The next step is to add support for more query