I was writing some property functions and one of them has a local part that is the same name as a built is and it seems to be loading my function and not the builtin one with the following warning
[main] WARN com.complexible.stardog.plan.filter.functions.FunctionRegistry - Multiple functions with same name 'contains', ignoring implementation class com.complexible.stardog.plan.filter.functions.string.Contains
I’m not sure why there was a conflict because the user defined function is using a fully qualified IRI and there are some warnings after that about "Local name conflict prohibits calling unqualified functions.
I didn’t think there would be a conflict but if there was a conflict I would have thought that the built in functions would have priority for being loaded.
Indeed, we will prioritize internal functions (which is a combination of XPath, XSD type casts, SWRL and SPARQL). You should still be able to call contains with the name <http://www.w3.org/2005/xpath-functions#contains>.
Allow functions to be called without namespace prefix (4054)
I’ll put together a quick test to see what exact function is being called
when there are multiple local names but I’ll just mention again that the
warning makes it appear as if the internal implementation is the one being
ignored. Hopefully it’s doing the right thing and it’s just the warning
that is incorrect or I’m misinterpreting it.
(In case anyone is wondering why I’ve been so quiet lately, I went on
vacation and when I returned my employer seems to have jacked up the
Stardog community web site for me so I can’t post. Hopefully responding to
emails like I’m doing now will work)
I’m back! At least for responses. I’ll have to wait to ask new questions
till I get home, obnoxiously tack them onto someone’s else’s question or
figure out how to create new threads over email I’ll keep you posted. I
was also responding in case anyone else missed that little feature
Just looping back on this. Is this the code you’re using?
If so, it looks like the function name argument you’re passing to the superclass constructor will be “contains” (not an IRI) as you called toString() instead of stringValue(). The conflict occurs because our internal implementation is called “contains” (not an IRI).