[
https://issues.jboss.org/browse/ISPN-7863?page=com.atlassian.jira.plugin....
]
Adrian Nistor commented on ISPN-7863:
-------------------------------------
I did some testing myself and found out in horror that an identifier starting with
'v', 'vv' or any number of 'v's is parsed wrongly by the lexer and
the 'v's are just dropped! In fact, looking at the lexer output, it appears the
'v's become a different token that is sent to a different channel, not the regular
channel, so it is not even seen by the next stage, the syntax parsing.
So if you have a query similar to "FROM User WHERE name = 'John''"
that executes correctly with your data model then "FROM vvvvvvUser WHERE
vvvvvvvvvvvvvname = 'John''" will execute as well without complaining
about un-existant type and property !!! The 'v's are just dropped by the lexer.
This has nothing to do with the presence of grouping or other more advanced syntax
features, it's just a lexer issue, and seems to be an ANTLR runtime bug. I've
tried upgrading to latest version from the 3 series - 3.5.2 and this does not seem to be
fixed. That's really bad, because the 3 series is dead and no longer maintained and
migrating to 4.x will imply a major rewrite of the grammar.
At least we know a temporary workaround for this issue: avoid starting your identifiers
with letter v (and maybe other letters too??). Interestingly, capital V works without
issues.
ISPN028501 (no property named) when access field after group by (by
only certain char's)
-----------------------------------------------------------------------------------------
Key: ISPN-7863
URL:
https://issues.jboss.org/browse/ISPN-7863
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 9.0.0.Final
Reporter: Gregory Orciuch
Assignee: Adrian Nistor
Links to:
https://issues.jboss.org/browse/ISPN-7861
When quering ISPN server over hotrod and trying to access field which begins with
"v" character that field access is lost but together with "group by"
operator.
Example of entity using proto/annotations:
{code:java}
@ProtoDoc("@Indexed")
public class Offering implements Serializable {
private String name;
private Integer relationSetId;
private Integer variant;
@ProtoDoc("@Field(store = Store.YES, analyze = Analyze.YES)")
@ProtoField(number = 5, required = true)
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
@ProtoField(number = 44)
public Integer getRelationSetId() {
return relationSetId;
}
public void setRelationSetId(Integer relationSetId) {
this.relationSetId = relationSetId;
}
@ProtoDoc("@Field(store = Store.YES, analyze = Analyze.NO)")
@ProtoField(number = 50)
public Integer getVariant() {
return variant;
}
public void setVariant(Integer variant) {
this.variant = variant;
}
}
{code}
Then executing query like this:
{code:sql}
select min(_gen0.name),min(_gen0.variant) FROM Offering _gen0 WHERE _gen0.variant = 44
GROUP BY _gen0.relationSetId
{code}
Produces server side error which mentions "ariant" - v - is lost. Paste is
below.
NOT using group by is causing that query to run well.
ALSO Changing variable name from variant to "bariant" helps.
LOOKS like there is some code which restricts the name or parses wrongly.
Affects not only simple type fields but also List<Variant> variants - "v"
is lost.
{panel:title=log}
14:02:50,951 DEBUG [org.infinispan.query.dsl.embedded.impl.QueryEngine]
(HotRod-ServerHandler-6-16) Building query 'select min(_gen0.name),min(_gen0.variant)
FROM Offering _gen0 WHERE _gen0.variant = 44 GROUP BY _gen0.relationSetId' with
parameters null
14:02:50,953 DEBUG [org.infinispan.server.hotrod.HotRodExceptionHandler]
(HotRod-ServerWorker-4-1) Exception caught: org.infinispan.objectfilter.ParsingException:
ISPN028501: The type Offering has no property named '*ariant*'.
at
org.infinispan.objectfilter.impl.syntax.parser.QueryResolverDelegateImpl.normalizeProperty(QueryResolverDelegateImpl.java:191)
at
org.infinispan.objectfilter.impl.syntax.parser.QueryResolverDelegateImpl.normalizeUnqualifiedPropertyReference(QueryResolverDelegateImpl.java:84)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.unqualifiedPropertyReference(QueryResolver.java:7651)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.propertyReferencePath(QueryResolver.java:7548)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.propertyReferenceExpression(QueryResolver.java:5689)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.valueExpressionPrimary(QueryResolver.java:5495)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.valueExpression(QueryResolver.java:5271)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.rowValueConstructor(QueryResolver.java:4490)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.predicate(QueryResolver.java:3326)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.searchCondition(QueryResolver.java:2979)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.whereClause(QueryResolver.java:655)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.querySpec(QueryResolver.java:510)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.queryStatement(QueryResolver.java:379)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.queryStatementSet(QueryResolver.java:292)
at
org.infinispan.objectfilter.impl.ql.parse.QueryResolver.statement(QueryResolver.java:220)
at org.infinispan.objectfilter.impl.ql.QueryParser.resolve(QueryParser.java:81)
at org.infinispan.objectfilter.impl.ql.QueryParser.parseQuery(QueryParser.java:69)
at
org.infinispan.objectfilter.impl.syntax.parser.IckleParser.parse(IckleParser.java:19)
at
org.infinispan.query.dsl.embedded.impl.QueryEngine.lambda$parse$1(QueryEngine.java:663)
at org.infinispan.query.dsl.embedded.impl.QueryCache.lambda$get$0(QueryCache.java:79)
at
org.infinispan.cache.impl.TypeConverterDelegatingAdvancedCache.lambda$convertFunction$1(TypeConverterDelegatingAdvancedCache.java:101)
at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
at
org.infinispan.cache.impl.AbstractDelegatingCache.computeIfAbsent(AbstractDelegatingCache.java:343)
at
org.infinispan.cache.impl.TypeConverterDelegatingAdvancedCache.computeIfAbsent(TypeConverterDelegatingAdvancedCache.java:161)
at org.infinispan.query.dsl.embedded.impl.QueryCache.get(QueryCache.java:79)
at org.infinispan.query.dsl.embedded.impl.QueryEngine.parse(QueryEngine.java:663)
at
org.infinispan.query.dsl.embedded.impl.QueryEngine.buildQueryWithAggregations(QueryEngine.java:299)
at org.infinispan.query.dsl.embedded.impl.QueryEngine.buildQuery(QueryEngine.java:139)
at
org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:91)
at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:98)
at
org.infinispan.query.remote.impl.QueryFacadeImpl.makeResponse(QueryFacadeImpl.java:61)
at org.infinispan.query.remote.impl.QueryFacadeImpl.query(QueryFacadeImpl.java:53)
at org.infinispan.server.hotrod.HotRodServer.query(HotRodServer.java:116)
at org.infinispan.server.hotrod.ContextHandler.realRead(ContextHandler.java:148)
at org.infinispan.server.hotrod.ContextHandler.lambda$null$0(ContextHandler.java:59)
at org.infinispan.security.Security.doAs(Security.java:143)
at
org.infinispan.server.hotrod.ContextHandler.lambda$channelRead0$1(ContextHandler.java:58)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
at java.lang.Thread.run(Thread.java:748)
{panel}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)