I'm getting a "Failed to read artifact descriptor for com.stardog.stark.io:stardog-stark-io-nquads:jar:6.0.1"
Seems to be fine for 6.0.0
Looks like our release process missed the stark jars for 6.0.1. I just pushed them up, can you try again?
I also fixed our release process so this hopefully won't be a problem again.
Thanks for pointing it out.
Paul
Looks good. 
Either I spoke too soon or something has changed but it looks like it's still having problems resolving the stark jars.
Sorry about that, I added the missing jars. Can you try again? You may have to clear your cache.
No worries. Success. Now I'm going to ask all kinds of questions about the new Stark interface.
ValueOrError.General is that just anything that isn't one of the specific types? I'll follow up in a different post but I've got something that I'd really like to do but I'm not sure if it's something I should do. It's super simple so I'll just give it a go and ask what you think.
Hi Zach,
ValueOrError isn't really a part of Stark API, it's the result of a refactoring to stop throwing Java exception for SPARQL expression evaluation errors, particularly, SPARQL type errors. It was a known performance problem. So now your functions should return ValueOrError.
There're classes for common result types, e.g. integers or booleans, but if you're returning some general Value, you should use ValueOrError.General.
Sure, happy to answer questions,
Pavel
Thanks. I'll get to ask all the dumb questions so others don't have to 
So I'm guessing if you have an error you'd just return ValueOrError.Error. I used to return an error message with ExpressionEvaluaitonException but now I suppose just throw it in a log message.
I also noticed that the assertions don't return the checked datatype. Is there a util to do that? I know I can just to the test and cast it but it isn't very pretty.
Right, exactly. Typically the code looks something like this:
if (!assertIntegerLiteral(args[0]) || !assertIntegerLiteral(args[1])) {
return ValueOrError.Error;
}
Literal first = (Literal) args[0];
Literal second = (Literal) args[1];Cool, just wanted to make sure there wasn't some util I should be using.
I'll share that possibly stupid thing that I'd like to do. For some reason, probably because I can't and that bothers me, I really want to be able to generate rdf lists from a sparql construct but I think it would require something like a window function. I created a simple one to test it out that returned the previous binding. It seemed to work but I always had the feeling that it might not always work and might have been a bit of a hack.
Well, it is most definitely a hack 
You're relying on two assumptions here that we don't really guarantee: that a function can maintain state across evaluations (i.e. that the same instance will be used for consecutive inputs) and that evaluations always happen sequentially. These are only generally true for aggregation functions (maybe you can somehow use those).
I agree that window functions would be the right way to approach it and we even have an open ticket to support them, but there's no target date yet. Meanwhile I think your assumptions will hold.
That's what I suspected but I notice that you didn't say, "....and don't do it" 
I was hoping to enforce the sequential evaluation by only using it in the projection and including an order by. I'll play with it but leave it in the experimental category which is also currently occupied by functions in javascript. I'm still looking into that. I'm not sure what the future status of Nashorn Java interpreter is and what I really want is node so I'm looking into j2v8 GitHub - eclipsesource/J2V8: Java Bindings for V8. It seems like a bit of a security nightmare but seems like it might be ok if you just don't allow arbitrary code execution. I'm also curious about running functions from a docker container. I've been working with OpenFaas lately and it might be cool if you could use the docker images that they build by running them locally.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.