transaction numeric, string, datetime, and hash functions #505
Conversation
src/fluree/db/query/exec/eval.cljc
Outdated
| [s start end] | ||
| (subs s start end)) | ||
| ([s start] | ||
| (subStr s start (count s))) |
There was a problem hiding this comment.
I think this is confounding length and endpoint. If start is not 1, the second argument to subStr will be longer that the length remaining. In any case, the built-in subs has an arity that accomplishes this case. i think (subs s (dec start)) is what you want here.
src/fluree/db/query/exec/eval.cljc
Outdated
| [s substr] | ||
| (-> (str/split s (re-pattern substr)) | ||
| first | ||
| str)) |
There was a problem hiding this comment.
why the extra str call here? Also, I don't think this matches the spec. If substr doesn't appear in s, the spec says to return an empty literal, but this will return s.
src/fluree/db/query/exec/eval.cljc
Outdated
|
|
||
| (defn strAfter | ||
| [s substr] | ||
| (-> (str/split s (re-pattern substr)) |
There was a problem hiding this comment.
It doesn't look like this matches the spec either. First, for the same reason as strBefore above, and also because the spec says to return the string after the first occurrence of substr, and this will return the string after the last occurrence of substr
| ledger @(fluree/create conn "functions" {:defaultContext [test-utils/default-str-context | ||
| {"ex" "http://example.com/"}]}) | ||
| db0 (fluree/db ledger) | ||
| db1 @(fluree/stage db0 [{"id" "ex:create-predicates" |
There was a problem hiding this comment.
What does this db1 step do? It looks like you're staging all the data you need for each test below, and we should be creating predicates on the fly as data is staged.
There was a problem hiding this comment.
That's an artifact of how I originally wrote the test harnesses, I can move the predicate creation into the relevant test cases.
https://www.w3.org/TR/sparql11-query/#SparqlOps 17.4.3 17.4.4 17.4.5 17.4.6 These had existing implementations that needed to be changed to comply: - rand: before it selected a random element from a collection, now returns a random number between 0 and 1. - now: before it returned an integer epoch milliseconds, now returns an ISO8601 datetime string - subStr before it took a start and optionally an end arg, now it takes a start and optionally a length arg These haven't been implemented: - md5, sha1, sha386: We don't have implementations for these and I didn't want to add a dependency for them. Figure we can add later at user request. - encode-for-uri: This seems more complex and I want to see if there's a straightforward way to get it without manually implementing https://www.ietf.org/rfc/rfc3986.txt - langMatches We don't currently support language tags
These are the functions that can be implemented without altering our existing query fn structure.
dpetran
force-pushed
the
feature/transaction-fns
branch
from
3070e6d
to
193c0aa
Compare
|
rebased on main to remove file conflict |
src/fluree/db/query/exec/eval.cljc
Outdated
|
|
||
| (defn year | ||
| [datetime-string] | ||
| (let [datetime ^LocalDateTime (datatype/coerce datetime-string const/$xsd:dateTime)] |
There was a problem hiding this comment.
What happens if we try to do this in javascript?
Also shuffled around some type hints. They didn't cause any problems where they were, but they were misleading. Also, `getYear` does not return what you'd expect in js, we need to rely on `getFullYear` instead.
This is the easy part of #232
implements numeric, string, datetime, and hash functions
https://www.w3.org/TR/sparql11-query/#SparqlOps :17.4.3, 17.4.4, 17.4.5, 17.4.6
Also includes a fix for #522
These had existing implementations that needed to be changed to comply:
before it selected a random element from a collection, now returns a random
number between 0 and 1.
before it returned an integer epoch milliseconds, now returns an ISO8601 datetime string
before it took a start and optionally an end arg, now it takes a start and optionally a
length arg
These haven't been implemented:
We don't have implementations for these and I didn't want to add a dependency for
them. Figure we can add later at user request.
This seems more complex and I want to see if there's a straightforward way to get it
without manually implementing https://www.ietf.org/rfc/rfc3986.txt
We don't currently support language tags
Outstanding work:
The datetime functions currently only work on datetime strings - not date strings, not time strings.
The functional forms (17.4.1) and functions on RDF terms (17.4.2) sections are a bit trickier. A lot of it already is implemented but the stuff that isn't requires additional context beyond just the value (subject, predicate, object).
Also, error handling is really subpar currently, I'd like to have very nice and helpful error messages when a function blows up.