search

OpenRefine / openrefine.org

Source website for openrefine.org
https://openrefine.org
Other
130 stars 117 forks source link

GREL get() function is misdocumented #341

Closed jquartel closed 1 month ago

jquartel commented 1 month ago

The documentation for the get() function states that it is "identical to substring() in relation to strings". However, its behavior with no "to" argument is different:

"profound".substring(3) produces the string "found", as documented, but "profound".get(3) produces just "f"

That is, when there is no 'to' argument, get() only returns the character (or element, in the case of arrays) specified by the 'from' argument. I have tested this with OR 3.8.1 . Of course, if get() is indeed meant behave the same way as substring then let me know and I'll turn this into a bug ticket in the OpenRefine repository.

Also in the documentation for get() is a statement "Also works with named fields", but there is no hint at what a 'named field' would be or what data type it pertains to. Could this be elaborated?

tfmorris commented 1 month ago

https://openrefine.org/docs/manual/grelfunctions#gets-n-from-n-to-optional

Yeah, that's pretty suboptimal. I think the references to descriptions substring() and array indexing should just be replaced with inline text.

"Also works with named fields", but there is no hint at what a 'named field' would be or what data type it pertains to

JSON objects and internal GREL objects, so you could, for example, write row.index as row.get("index") (although I'm not sure why you'd want to do all that extra typing).

ostephens commented 1 month ago

JSON objects and internal GREL objects, so you could, for example, write row.index as row.get("index") (although I'm not sure why you'd want to do all that extra typing).

Generally you wouldn't, but if the property has a space (or other from a set characters - I can't remember the details right now) then you can't use the dot notation and have to use get() instead

ostephens commented 1 month ago

This behaviour is long standing in OpenRefine so I think probably better to fix the documentation than change the behaviour.

@jquartel I've made an attempt to fix if you want to have a look. The wording still feels a little clumsy to me so happy to accept suggestions if you think it could still be clearer