So if we don't want to use ~ here, I am fine with that. However I do not want this used for full text searching.
On Sat, Aug 29, 2015, 6:07 PM Sanne Grinovero <sa...@hibernate.org> wrote: > I think we all agree that we want at least the high level intent of an > HQL query to be understandable without having to keep a reference > sheet of its special symbols at hand. > > I would interpret that "~" symbol differently, so I don't think it's > suited to imply some special meaning related to "null" and while I > normally understand we argue about "naming things" as we all have > different language backgrounds, this one seems universally established > in the scientific world, so I'm afraid that it would look a really odd > choice to most users. > > Gunnar's proposal looks better, as that's commonly used in similar > scenarios: beyond Groovy, it's commonly used for ternary operator > which is essentially a short hand for a conditional: > - https://en.wikipedia.org/wiki/%3F: > > On full-text query, looks like a clarification is in order on why I > was thinking about that symbol specifically: > A full-text query goes far beyond "containing" some keywords; for > example it can provide matches on synonyms, disregard typos, expand > acronyms, or even give different semantic value for words depending on > their position and role in a sentence. The match is really about > "search stuff which is semantically similar to this". > I realize that most SQL technologies provide only a limited subset of > such options, and that's exactly why we provide alternatives like > Hibernate Search which do much more and better ;-) > i.e. with Search such an operator would mean "equals or almost > equals", for some definition of "almost equals" which we allow the > user to specify precisely in the mapping and configuration. > > Thanks, > Sanne > > On 29 August 2015 at 18:21, Steve Ebersole <st...@hibernate.org> wrote: > > Sorry, but I agree with Brett. CONTAINS is a much more natural way to > > perform a full-text search, especially for those coming from SQL. > > > > On Sat, Aug 29, 2015 at 1:47 AM Gunnar Morling <gun...@hibernate.org> > wrote: > > > >> I like the idea of a new operator, but I side with Sanne that "~" > >> would be useful for similarity/full-text searches. > >> > >> What about "?=", somewhat inspired by Groovy's Elvis operator? It > >> seems nicer to me for expressing null-awareness. The pattern could > >> even be generalized by using the operator prefix for making some more > >> comparison operators null-aware: "?<", "?>" etc. > >> > >> --Gunnar > >> > >> > >> > >> 2015-08-28 16:36 GMT+02:00 Brett Meyer <br...@hibernate.org>: > >> > +1 to ~. Sanne has a good point, but I think I'd rather see a > function > >> > name there (CONTAINS, etc.). > >> > > >> > On 08/28/2015 10:09 AM, Sanne Grinovero wrote: > >> >> On 28 August 2015 at 15:02, Steve Ebersole <st...@hibernate.org> > wrote: > >> >>> What do y'all think of using a symbol like ~ for this? The idea > would > >> be > >> >>> similar to the "wavy equals" from logic used to denote > "approximately > >> >>> equals". > >> >> I was hoping that one day we would be able to use the '~' symbol for > >> >> full-text queries, i.e. a fuzzy match for text fields to extend HQL. > >> >> But we have no concrete plans about that, and we currently don't do a > >> >> great job in allowing people to combine full-text restrictions with > >> >> relational restrictions, so that might be an unrealistic dream. > >> >> > >> >> > >> >>> On Thu, Aug 27, 2015 at 7:05 AM andrea boriero < > and...@hibernate.org> > >> wrote: > >> >>> > >> >>>> i like the idea of "matches" operator for dealing with "is null". > >> >>>> +1 > >> >>>> > >> >>>> On 26 August 2015 at 19:32, Steve Ebersole <st...@hibernate.org> > >> wrote: > >> >>>> > >> >>>>> https://hibernate.atlassian.net/browse/SQM-11 > >> >>>>> _______________________________________________ > >> >>>>> hibernate-dev mailing list > >> >>>>> hibernate-dev@lists.jboss.org > >> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >>>>> > >> >>>> > >> >>> _______________________________________________ > >> >>> hibernate-dev mailing list > >> >>> hibernate-dev@lists.jboss.org > >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> _______________________________________________ > >> >> hibernate-dev mailing list > >> >> hibernate-dev@lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> > > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev@lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
