Repository navigation
update queries: strange behaviour on SET EXPR #158
Description
i tried to run this query:
UPDATE [nt:unstructured] AS a INNER JOIN [nt:unstructured] AS t ON ISCHILDNODE(t, a)
SET expr('row.getNode("t").setProperty("originalLinkCaption", row.getNode("a").getPropertyValue("originalLinkCaption"))')
WHERE a.[phpcr:class] = 'Liipch\MagazineBundle\Document\Article' ;
but during the autosave i get the exception
[PHPCR\ValueFormatException] Invalid value for property ")": Object values must implement PHPCR\NodeInterface, PHPCR\PropertyInterface or be \DateTime, supplied argument is of class: PHPCR\Shell\Query\ColumnOperand
as SET EXPR does not exist, this should report an error instead of trying to do strange things. there is probably a problem with the query parser.
Activity
dantleech commentedon May 5, 2015
I don't think so.. looks like a parser issue. Maybe try escaping the quotations?
dantleech commentedon May 5, 2015
hmm .. i get the same issue
dantleech commentedon May 5, 2015
Try:
dbu commentedon May 5, 2015
i tried that, it leads to the bug described in #160
dantleech commentedon May 5, 2015
Hmm, it works for me locally (it parses the query and updates 0 rows). Are you using the latest version? (beta-3)
dbu commentedon May 5, 2015
dbu commentedon May 5, 2015
ok, your proposal works. but the thing i reported still gives me the same on beta3 and i don't think i see a typo in there. so maybe a bug in the expression parser?
functions got case sensitive, so its actually
exprand notEXPRdantleech commentedon May 5, 2015
So you can update your content repository sucessfully?
Is the bug that it should be case insensative? (in addition to actually locating the exception class)
dbu commentedon May 5, 2015
so the
SET EXPR()syntax seems not case sensitive, but thea.field = expr()case only works lowercase. maybe that is by design - not sure but maybe functions should generally be case insensitive. would be more in line with the sql keywords being insenstitive.a.field = expr()worked for me with beta3.SET EXPR()does not.dantleech commentedon May 5, 2015
Hmm, well
SET EXPRis invalid as SET is alwaysfield => value. We could implementAPPLY EXPR()dbu commentedon May 5, 2015
oh, but then the parser is really not reporting that one well. it executed something and the error comes on the auto-save. i will adjust the ticket description then
[-]update queries: EXPR not working[/-][+]update queries: strange behaviour on SET EXPR[/+]