Is behaviour different when you first upgrade your community instance to the latest 3.5.x (.20 at the moment) and THEN upgrade to the enterprise version?
Thanks for your reply. Both my instances are on enterprise already so this might be a bit late. I think I could roll back to the original community 3.5.16, test, go to community 3.5.20, test, and then do enterprise 3.5.20.
If I roll back to community 3.5.16 and the issue is still present, what could this mean? Have you seen a similar problem before?
Have you tried explicitly defining and querying an index?
Yes, there is an id field on my :AWSTag node that I have created an index for.
I originally discovered this issue when I ran a query to find all tags of an EC2Instance node with match(n:EC2Instance{publicipaddress:"1.2.3.4"})--(a:AWSTag) return a.id
and noticed that queries on a.id with prefixes of aws:autoscaling:groupName* did not work even though they show up in queries to connected nodes. For example, this returns 0 results even though I know this node exists:
match(t:AWSTag{id:"aws:autoscaling:groupName:MY_GROUP_NAME"} return t
Hi there, I faced the same issue and ended up using Regular Expressions, though I'm not sure how much more resource consuming this is.
Look at the WHEN clause:
FOREACH (ignoreMe IN CASE WHEN (m.body =~ '(?ms).+Esta informaci.n te result. .til.+') and (m)-[:SENT_BY]->(:Nubot) THEN [1] ELSE [] END | \
SET m:Recommendation \
) \
I looked into this issue and found the problem, we were removing ":auto" from cypher queries. The fix will make into this or next release, thanks for reporting this issue!
For a little more context, in the browser we can prefix a query with :auto to change how it's executed (this is required when you run a USING PERIODIC COMMIT LOAD CSV kind of query), and it looks like we were being a little lazy with how we removed the :auto part (since this would be a browser command that only the browser should interpret, and it would need to be removed from the Cypher before sending).