Separate Query / QueryBuilder namespace from the rest of the package?

[mfn]

Hello 👋🏼 ,

I'm a happy user for years of this package and acknowledge that there are no plans to support OpenSearch.

In my case I don't use the Elasica client but only the Query part as a DSL to safely build the queries and not make stupid nesting and whatnot mistakes.

Due to this package being more than just the Query DSL part, it has a dependency on elasticsearch/elasticsearch.

I probably know the answer, but I was wondering if there are plans to separate the query / builder / dsl part from the rest in a separate package, which by itself would not have a dependency on a specific client?

(I only did a cursory look but from the looks of it, I got the impression it could work).

thanks

[ruflin]

Hi @mfn A few years ago, Elastica did not have a dependency on the elasticsearch/elasticsearch lib. I added it back then to be able to remove some of the code from Elastica and benefit from improvements made in the elasticsearch client, especially around transport. The plan was always to remove much more code from Elastica and rely more on the client and with it automatically also get new features quicker. Well, you know how it is. We started but never completed.

As usual, taking parts out as a lib is work. If you are interested to take on this work in a separate repo, no objections on my end ;-)

[mfn]

Thank you, that sounds actually encouraging 😄

I took a more in-depth look and what immediately stood out was that:

• Elastica\Test\Query\*
  as well as
• \Elastica\Test\QueryTest

contains functional test.

Those functional test use the \Elastica\Client, which makes separating any of this challenging. Besides, my initial idea was to keep this functional integration out of a pure DSL package.

1. But either we would loose those tests (don't like this)
   or
2. keep them in this package (maintenance nightmare)
   or
3. come up with a custom solution to keep them in the new package (directly using elasticsearch-php?)

Then of course we haven't yet talked how to integrate this back, namespace & naming.

Overlapping namespaces shouldn't be an issue, e.g. having namespace Elastica\Query in a different package. This package would depend on it so the transition could "just work".

But classes like \Elastica\Query and \Elastica\QueryBuilder are not in that namespace and need to be moved (BC break). For a transition a class_alias() workaround could be done for some time (I've seen other packages transition from Name_Space to Name\Space using this successfully).

(git history was also a concern but we could simply keep this repo history for the new one, why not).

Obviously that's not a 5min job and takes careful planning and coordination. And it's not like I have any kind of contribution track record here 😅

I'll leave this for now to hear more thoughts how you/others think about the feasibility or alternative ideas. Or outright saying if you even think it's worth it.

Thanks for your time!

[ruflin]

Even though extracting query / querbuilder would be nice, I must confess I'm slightly worried that Elasticsearch and Opensearch will diverge more and more from each other. So eventually, Elastica would have a dependency on a query lib that tries to cover 2 diverging solutions. Also having query and query builder in its own repo, would mean contributing to Elastica becomes harder. At the moment everything is neatly together in one place and not only makes contributions but also maintenance easy which is important for me.

Why would 2 be a maintenance nightmare?

[mfn]

Why would 2 be a maintenance nightmare?

It would mean that:

• this repo contains the function tests
• for the query/query builder stuff in the other repo

That sounds like a maintenance nightmare and feels backwards to have code run a test in here which is actually from a different package.

---

At the moment everything is neatly together in one place and not only makes contributions but also maintenance easy which is important for me.

TBH, I share this sentiment too. This create a possible rift.

The primary reason is that ppl using OpenSearch wanting to benefit of the builder also have the elasticsearch-php dependency, even though it's not even "used on the context of the user of this part of the library" and usually they have openseach-php installed, too

I think if I'm the only person ever spoken up about this, it hardly justifies any of this work :-}

cheers

[ruflin]

Lets keep this thread open and see what others thing. But agree, at the moment lots of work around this is hard to justify.