Hibernate Books

All times are UTC - 5 hours [ DST ]



Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: 'LIKE' query operator not well supported in Neo4j
PostPosted: Thu Feb 16, 2017 3:35 pm 
Beginner
Beginner

Joined: Thu Jan 05, 2017 1:47 pm
Posts: 27
I've encountered a couple problems trying to use the LIKE operator.

1) It doesn't work when the pattern is a query parameter. The error happened with it tried to cast a Neo4jQueryParameter to a String on the last line of Neo4jQueryRendererDelegate.predicateLike(). I no longer have the exception trace for that though.

2) The ESCAPE clause doesn't seem to work - after the core Hibernate code parses the query successfully, I get the following exception:

Caused by: org.hibernate.hql.ParsingException: HQL000002: The query SELECT e FROM com.nokia.nspos.model.domain.mock.entities.MockEntity e WHERE (mockString LIKE 'i' ESCAPE '\') is not valid; Parser error messages: [[statement, statementElement, selectStatement, queryExpression, querySpec, whereClause, logicalExpression, expression, logicalOrExpression, logicalAndExpression, negatedExpression, equalityExpression, relationalExpression, concatenation, additiveExpression, multiplyExpression, unaryExpression, atom, expressionOrVector, expression, logicalOrExpression, logicalAndExpression, negatedExpression, equalityExpression, relationalExpression, likeEscape, concatenation, additiveExpression, multiplyExpression, unaryExpression]: line 1:108 state 0 (decision=68) no viable alt; token=[@35,108:108='<EOF>',<-1>,1:108], [statement, statementElement, selectStatement, queryExpression, querySpec, whereClause, logicalExpression, expression, logicalOrExpression, logicalAndExpression, negatedExpression, equalityExpression, relationalExpression, concatenation, additiveExpression, multiplyExpression, unaryExpression, atom]: line 1:108 mismatched token: [@35,108:108='<EOF>',<-1>,1:108]; expecting type RIGHT_PAREN].
at org.hibernate.hql.QueryParser.parseQuery(QueryParser.java:70)
at org.hibernate.ogm.datastore.neo4j.query.parsing.impl.Neo4jBasedQueryParserService.parseQuery(Neo4jBasedQueryParserService.java:40)
at org.hibernate.ogm.query.impl.OgmQueryTranslator.getLoader(OgmQueryTranslator.java:135)
at org.hibernate.ogm.query.impl.OgmQueryTranslator.doCompile(OgmQueryTranslator.java:122)
at org.hibernate.ogm.query.impl.LegacyParserBridgeQueryTranslator.compile(LegacyParserBridgeQueryTranslator.java:55)
at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:115)
at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:76)
at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:150)
at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:302)
at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:240)
at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1907)
at org.hibernate.engine.spi.SessionDelegatorBaseImpl.createQuery(SessionDelegatorBaseImpl.java:369)
at org.hibernate.ogm.jpa.impl.OgmEntityManager.createQuery(OgmEntityManager.java:246)


Top
 Profile  
 
 Post subject: Re: 'LIKE' query operator not well supported in Neo4j
PostPosted: Fri Feb 17, 2017 3:00 pm 
Hibernate Team
Hibernate Team

Joined: Fri Sep 09, 2011 3:18 am
Posts: 295
Thanks for the feedback. I'll check


Top
 Profile  
 
 Post subject: Re: 'LIKE' query operator not well supported in Neo4j
PostPosted: Mon Feb 20, 2017 11:42 am 
Hibernate Team
Hibernate Team

Joined: Fri Sep 09, 2011 3:18 am
Posts: 295
You spotted two bugs
Quote:
1) It doesn't work when the pattern is a query parameter. The error happened with it tried to cast a Neo4jQueryParameter to a String on the last line of Neo4jQueryRendererDelegate.predicateLike(). I no longer have the exception trace for that though.


I've created jira OGM-1255 for this: https://hibernate.atlassian.net/browse/OGM-1255

2) The ESCAPE clause doesn't seem to work - after the core Hibernate code parses the query successfully, I get the following exception:

It seems there is a problem in the parser and it is not able to recognize '/' as an esacper character, it seems to work if you use '*', this is still a bug and I've created issue OGM-1154 for it: I've created jira OGM-1255 for this: https://hibernate.atlassian.net/browse/OGM-1255

Thanks for the feedback, it's late now to include them for 5.1 Final but I'll include them in 5.2


Top
 Profile  
 
 Post subject: Re: 'LIKE' query operator not well supported in Neo4j
PostPosted: Mon Jun 19, 2017 12:05 pm 
Beginner
Beginner

Joined: Thu Jan 05, 2017 1:47 pm
Posts: 27
Incidentally, a double-backslash does work. But it fails to perform its jobs as an escape character for wildcards:

... where x like '%a\_b%' escape '\\'
... where x like '%a\%b%' escape '\\'

cause a parser exception. Oddly, the following:

... where x like '%a\\b%' escape '\\'

seems to work as expected though.

Stepping through the code, it does seem to designate a single '\' character as the escape, down in LikeExpressionToRegExpConverter.

I tried:

... where x like '%a\\_b% escape '\\'

which didn't cause an exception, but didn't produce the expected results.


Top
 Profile  
 
 Post subject: Re: 'LIKE' query operator not well supported in Neo4j
PostPosted: Tue Jun 20, 2017 3:27 pm 
Beginner
Beginner

Joined: Thu Jan 05, 2017 1:47 pm
Posts: 27
After much playing and searching, I think I understand what's all going on here with literal expressions and escape characters. The HQL parser itself doesn't use the escape character as specified when parsing the expression. It has a hard-coded '\' as the escape character in its lexer, and only allows very specific constructs to follow that. See here: https://github.com/hibernate/hibernate- ... HQLLexer.g

Which explains why the backslashes need to always be doubled-up in the expression or escape character strings. This I can deal with.

But then there's a couple problems with LikeExpressionToRegExpConverter. For starters, the escape character doesn't default to '\' if not specified, although I'm not sure I found a definitive answer as to whether that is supposed to be the case.

The next problem is that it doesn't deal with the expression encoding as given to it by the parser. Those extra escape sequences, as defined in the lexer, all come through exactly as found in the HQL string. So if we have '\134' in there to do an octal escape, then '\134' shows up at the converter, and no code converts that to the character equivalent. Nor are double-backslashes, e.g., converted to single.

I added a replaceAll in the converter, before applying the state machine, to undo the doubled-up backslashes, and was able to get the expression conversion to yield the right result. This doesn't cover all the other escape sequences the lexer supports, of course. And I'm not sure this would work with query arguments, once those are supported, as presumably the lexer's escape sequences wouldn't be expected in a query argument.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.