Transactions for SPARQL?

[fkleedorfer]

We are looking into using Blazegraph as the database backend of a nodejs based application, and we cannot figure out how to use transactions in such a setup. Here's what we think we know:

• Blazegraph has a REST Transaction API.
• SPARQL 1.1 does not specify transactions
• However, there is an unofficial draft specification for SPARQL Transactions that looks a bit like the blazegraph REST Transaction API. It specifies a header, Transaction-Location, for passing the transaction id along with the SPARQL query.
• The blazegraph database backend supports transactions, you can use them in the java API
• The js library we want to use is sparql-http-client, which allows for adding headers

Is there any way to use the transaction API and send SPARQL queries/updates within the transaction? If not: to the uninitiated, it looks like a really small adjustment to pass the Transaction-Location header value as the transaction id to the query processor. Would that be a 'good first issue' for us?

I understand that a single SPARQL request is atomic, so it should always be possible to collect all the work you would normally want to do in a transaction and put it all into one request. However, we would like to avoid having to do that, if possible.

Thanks in advance for your help!

[eltonfss]

Looking at REST Transaction API I was also unable to identify whether Blazegraph default operation mode is autocommit, as in Apache Jena Fuseki. Does the server open a transaction for every write request sent through the REST API, or transactions as disabled by default?

[thompsonbry]

Ever request is automatically committed when it is processed.

On Mon, Jan 24, 2022 at 12:46 PM Elton Soares @.***> wrote:

Looking at REST Transaction API https://github.com/blazegraph/database/wiki/REST_API#transaction-management-api I was also unable to identify whether Blazegraph default operation mode is autocommit, as in Apache Jena Fuseki. Does the server open a transaction for every write request sent through the REST API, or transactions as disabled by default?

— Reply to this email directly, view it on GitHub https://github.com/blazegraph/database/issues/165#issuecomment-1020531540, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATW7YFGZXZCNLKSDKEHWMLUXW3BZANCNFSM4N2KQLIQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[danjhugo]

@fkleedorfer Did you ever get read-write transactions working with the SPARQL REST API?

[fkleedorfer]

Yes, but not with blazegraph.

I ended up using an RDF4J server and client, with graphdb as the server. For the client, we implemented a spring integration for RDF4J and contributed that. I can recommend this approach.

However, we do not use SPARQL in the client (browser), because we were unsure how to implement fine-grained access control. Instead, we have a spring-boot server that offers a GraphQL API, talks to keycloak for access control and to the back-end via SPARQL.

[danjhugo]

@fkleedorfer cool, I was looking into RDF4J recently. I'll check out your module.