support transaction functions

[dpetran]

• now
• cas
• inc
• dec etc.

[dpetran]

Do we have a complete list of transaction functions we intend to support?

[bplatz]

I think they should be in the spirit, or similar, to the SPARQL function list. Then we extend those for whatever we don't cover, and some won't be applicable likely in a transactional context.

But I sort of feel like that's the place to start, and then here adjust what is supported there ideally after we implement them in query.

Also, using delete and update (which isn't in there yet, only delete is thus far) eliminate the need for at least CAS/compare and swap.

I'm basically saying there is still a good amount of work here to spec, and it should closely align with query functions. https://www.w3.org/TR/sparql11-query/#SparqlOps

[bplatz]

now was one we used to use I think a decent amount... this does have a SPARQL version: https://www.w3.org/TR/sparql11-query/#func-now

[zonotope]

I think most if not all of these are/can be supported with the new update ({:delete ..., :insert ..., :where ...}) operation syntax in combination of a :bind or :filter pattern within the :where clause. Here are the currently supported bind/filter functions

cas is supported implicitly by the update syntax, and we can trivially add functions like inc, dec, etc to the compiler.

[mpoffald]

Removing the "needs specification" label, the task is to make this list of functions work: https://www.w3.org/TR/sparql11-query/#SparqlOps

Per @zonotope , several of these should be largely trivial, and based on the existing method of supporting bind/filter functions.

[dpetran]

Here's what's not implemented yet:

Functional forms:

• exists
• sameTerm
• in (I think this could be covered by values bindings in the where-clause, though having syntax sugar for it may be nice)

Scalar functions:

• isIRI
• isBlank
• isLiteral
• isNumeric
• str
• lang
• datatype
• IRI/URI
• BNODE
• STRDT
• STRLANG
• UUID
• STRUUID

String functions:

• STRLEN
• UCASE
• LCASE
• CONTAINS (we call it subStr, maybe we should create an alias?)
• STRBEFORE
• STRAFTER
• ENCODE_FOR_URI
• CONCAT
• langMatches
• REGEX (we call it re-pattern)
• REPLACE

Numeric functions

• round
• ceil
• floor
• rand

Date/time functions

• year
• month
• day
• minutes
• seconds
• tz

Hash functions

• MD5
• SHA1
• SHA256
• SHA384
• SHA512

I think it may be worthwhile to break this into separate tickets, maybe for each class of functions.

[zonotope]

ciel, floor, and rand are already implemented, and they've also been added to the compiler

[zonotope]

It might make sense to split exists out into it's own ticket. That one will be a little tricky because it involves trying to match the pattern against an existing solution instead of operating wholly on the solution itself, so this will have to be implemented outside of the infrastructure defined in the fluree.db.query.exec.eval namespace.

[dpetran]

Splitting the following functions out into a new ticket because they require more substantical changes:

• isIRI/isURI
• isLiteral
• lang
• datatype
• IRI
• bnode
• strdt
• strLang
• exists/not exists
• sameTerm
• in/not in

https://github.com/fluree/db/issues/512 https://github.com/fluree/db/issues/513