This project has moved and is read-only. For the latest updates, please go here.

Thoughts about B* production usage

Apr 13, 2014 at 10:27 AM
Edited Apr 13, 2014 at 7:58 PM

After some time using B* api I think there is a problem with using it in production in any form: B* db or sparql connection to other db's, so it feels like a great product that is almost , but not, production ready.

1 .If using B* db directly there will probably be various problems with memory/ query optimizer/ performance/ scalability/ lack of various extensions/etc caused by the fact it doesn't have lot of production usage compare to other triple stores.

2 . If using the EF api to connect to other stores it's clear it has not been tested for this case so you will get into various problems. In the end the feature to connect to other sparql store is not usable unless there is at least one store that was testes and it works (at least all core EF tests pass).

A developer can find fixes, but has to report them on the forum, maybe create a fork and if the solution seems ok it will be accepted. If solution is not ok it won't get accepted and then you have to discuss. Considering a developer doesn't have great knowledge of the api finding good solutions means a lot of time, far more than someone who knows it.
This whole process takes a long time, and if there are multiple issues this means months.

So I think the key to make people use the EF api is to have real support for other specific stores (preferably free ones). For example the answer to this question should be B* EF api.

For people to use actual EF api with B* database I will write another post.
Apr 14, 2014 at 10:07 AM

Thanks for the feedback. I agree with your two main points. Firstly B* is still under development, so it is probably not yet "product ready" for all values of "production". I think it is perfectly usable as an embedded triple-store though and the API is relatively stable which means that it is possible to develop now with some level of confidence that 1.7 won't break all your code.

EF-to-SPARQL is not production ready and this should probably be explicitly spelled out in the documentation. The cold hard fact is that I don't have the time or the resources to test compatibility with all the different stores that are out there, so I am relying on bug reports and pull requests from developers who have a particular store they want to integrate with. If there are no developers that are out there willing to put in the time and effort like you have, then it may be some time before I can get around to really working on that stuff.