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

Solr Criteria Query Builder #420

Open
dewos opened this issue May 15, 2016 · 11 comments
Open

Solr Criteria Query Builder #420

dewos opened this issue May 15, 2016 · 11 comments

Comments

@dewos
Copy link
Contributor

dewos commented May 15, 2016

Hello there. As has already been mentioned in #123 (@basdenooijer), I would like to help the project with a fluent query builder. I made an PHP implementation of Java Spring Solr Criteria , and soon I'll tag a stable release. You can find it here: https://github.com/minimalcode-org/search

You could "suggest" it (composer or documentation) or use it directly as the official builder, I don't care for the credits. My advice actually is to do something like aliasing, for keeping the namespace in Solarium context:

<?php
namespace Solarium\Core\Query;

use Minimalcode\Search\Criteria as BaseCriteria;

class Criteria extends BaseCriteria {}

I hope it is useful, and I'm open to comments and suggestions, thanks 👍

@basdenooijer
Copy link
Member

Nice work, it looks interesting 👍

I think your library can be used with Solarium perfectly without a special integration. We can suggest it in the docs, and maybe include an example. Anyone who wants to use it can easily do so using composer, and we could also consider to add it to the composer file as a suggested package.

I don't think we need to create a namespace alias, people are getting used to the trend of small libraries for a specific purpose, instead of big monolithic libraries.

@dewos
Copy link
Contributor Author

dewos commented May 19, 2016

I wanted to gift it to solarium, but a suggestion in the doc with some examples is also a very good idea @basdenooijer. I'm committed to keeping the repo online and alive anyway.

And yes, luckly the PHP community has evolved very much in recent years, maybe I could contact the other "Solr-Php libraries related" (FloriansemmSolrBundle etc..) for extending the invitation on them too.

See you next time, and congratulations for the project. 👍

@basdenooijer
Copy link
Member

basdenooijer commented May 24, 2016

Great, next time I'm editing the docs I'll try to remember to add this. Or, if you want to, you can also send a PR with updated docs

@bpolaszek
Copy link
Contributor

Hello Dewos,

Your work looks great !
Do you use the Doctrine library ?

Their code looks very similar: http://doctrine-orm.readthedocs.io/projects/doctrine-orm/en/latest/reference/working-with-associations.html#filtering-collections

The big advantage of their "criteria" implementation is that it's not coupled to SQL filtering, even not to the Doctrine ORM itself.

You can grab the standalone library here: https://github.com/doctrine/collections

Doctrine currently has 2 implementations:

  • Transforming criteria expressions into SQL syntax
  • Transforming criteria expressions into PHP (for filtering an array, for instance).

It would be great to adapt your work to their interfaces and make a pull request to them. This would allow to use the same library to filter any time of collection, wether it's a SQL table, an array, or a Solr collection.

I was beginning the same work as yours before I saw your post and discovered your library :)

@dewos
Copy link
Contributor Author

dewos commented Jun 3, 2016

Hi @bpolaszek, thanks for your kind words.

I know about Doctrine Criteria, but even if the interfaces are indeed implementable, the "Jack of all trades, master of none" road is probably not the best one. Concepts like boosting, or geospatial, or fuzzy and so on, are specific for a documental system, and don't play well with other domains.

Furthermore, I like my Criteria API more, Doctrine's one is a bit cucumbersome in my opinion :)

@dewos
Copy link
Contributor Author

dewos commented Jul 13, 2016

Hi @basdenooijer . Now that much we have all agreed upon, that the PHP community would benefit from a query builder.

The simplest and fastest solution is to just pursue your idea to sponsorize the stand-alone library (@floriansemm could do the same on the bundle). Just that would help a lot, and it can happen tomorrow.

A solariumphp/builder repository is also an equivalent solution. The important thing is to direct the community towards an agreed solution. Speaking of which, I wouldn't worry too much about the time required, as probably there is not so much else to do to Criteria, features wise.

Like I said it is the result of many years of java-community brainstorming, and in my opinion is a very good solution for 90% of the use-case. It would be a good idea to keep the API as it is right now, at least initially, to facilitate developers that switch between the two languages.

@bmeynell
Copy link

@bpolaszek @dewos

... are specific for a documental system, and don't play well with other domains.

Not advocating one approach or another but Doctrine also has a Query Builder for MongoDB which is a "documental system". Older than Doctrine is Propel's Criteria Object, which IIRC was a PHP port of the Apache Torque ORM. FWIW.

@dewos
Copy link
Contributor Author

dewos commented Jul 14, 2016

@bmeynell wait, despite the name they are two very different projects.

  • doctrine/collections is a very light abstraction for dealing with generic domains
  • doctrine/mondodb is a full stack ODM for MongoDB (that extends doctrine/collections)

Now, the idea of @bpolaszek was to implement the first one, but as I said it is domain-agnostic, so only the basic expressions (equals, into etc...) are fine.

Sure, it is possibile to extend it like Doctrine MongoDb does with additional expressions, but then when you try to "boost" or "search by position" an array or a Doctrine ORM Result the system blow up (as it should be): the two domains don't play well.

So the effort is not totally worth it (also, the API would be more cucumbersome, and the memory usage of the doctrine's api is much higher).

@cmezat
Copy link

cmezat commented Sep 2, 2016

@dewos OMG! Your Criteria class saved me from pulling my hair out. I couldn't understand how to do what I wanted programmatically until using your library. I thought Solarium was supposed to help in that regards, but in the end, I'm doing 3 total lines of Solarium to get what I need to done:

        $query = $this->client->createSelect();
        $query->setQuery($criteria->getQuery());
        $results = $this->client->execute($query);

The rest of the magic happens with Criteria. Thank you. Please get an official release out so Composer works! ;)

@dewos
Copy link
Contributor Author

dewos commented Sep 2, 2016

Oh well @cmezat, thank you. Glad it helped :)

P.s. I just tagged a new version as stable.

@cmezat
Copy link

cmezat commented Sep 2, 2016

Awesome! Thanks.

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

5 participants