update queries: strange behaviour on SET EXPR

[dbu]

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.

[dantleech]

I don't think so.. looks like a parser issue. Maybe try escaping the quotations?

[dantleech]

hmm .. i get the same issue

[dantleech]

Try:

UPDATE [nt:unstructured] AS a INNER JOIN [nt:unstructured] AS t ON ISCHILDNODE(t, a) 
SET t.originalLinkCaption = EXPR('row.getNode("a").getPropertyValue("originalLinkCaption")') 
WHERE a.[phpcr:class] = 'Liipch\MagazineBundle\Document\Article' ;

[dbu]

i tried that, it leads to the bug described in #160

[dantleech]

Hmm, it works for me locally (it parses the query and updates 0 rows). Are you using the latest version? (beta-3)

[dbu]

oh, actually not. i will try that out and report back.

[dbu]

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 expr and not EXPR

[dantleech]

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]

so the SET EXPR() syntax seems not case sensitive, but the a.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]

Hmm, well SET EXPR is invalid as SET is always field => value. We could implement APPLY EXPR()

[dbu]

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