Why on earth has the Go Driver been linked to Seabolt / so painful. We have even tried the static link approach however that is broken as it required dependencies on CLIB and then versions get misaligned . This approach feels SO not Golang Package.
Anyone have any suggestions for a better and friendly driver for Production environments ?
We've been bitten !
As far as I know the only other native Go driver around is the community developed one, but the author is no longer maintaining it. Might be able to fork it and keep it updated.
As for the Seabolt issue, I couldn't agree more. It ended up being the deciding factor to switch away from Neo4j for our company, especially when we started adding more developers to the team.
Thanks for the suggestion / We had been using GitHub - go-cq/cq: neo4j cypher library for database/sql in go before trying the official driver. Maybe Neo4J guys could provide some sponsorship to have one of these opensource GO drivers maintained / I suspect there are many more Golang developers would prefer such an approach.
From my experience it looks like we're out of luck for an official native go driver. I've expressed my concerns over on the slack a few times before making the switch since working seabolt into a golang workflow was a pain, and there was some major performance issues, along panics when using goroutines for database interactions since threads are being spawned when it goes from Go to C. They did fix the goroutine issue, but that added even more of a performance hit.
I think the reason we have an official golang driver is because they planned on making a C driver and saw an opportunity to add another language to the marketing material through cgo.
Hopefully in the future something is done about Seabolt, but as of right now I personally don't think the current solution lives up to Go.
Sorry that you've both had trouble with the Go driver. You're absolutely right (Matt) that the driver was a "bonus" spin-off from the C library work - we saw an opportunity to fill a need for the Go community which we hoped would be useful. Unfortunately, it appears not to have been so useful for all Go users. That said, we do have some customers using it, and we therefore know it can work in some environments.
But obviously that's not much comfort for those such as yourselves who are having trouble :(
We've taken your feedback on board and as and when time and people allow, we'll look into the possibility of a native Go driver. Unfortunately, I can't give any timings around that, so for the meantime, the only other options will be a community driver or the HTTP interface. The latter might be your best bet as it offers regular Cypher execution, with transactions, with only a few restrictions around the type system (due to JSON limitations). We are working on bringing HTTP up to date in our next release too, so it's perfectly safe to build upon.
Thanks Nigel @technige / this is positive news. Indeed I can understand it's possible to get this running in production however with multiple moving pieces and dependencies it's is unfriendly / and likely to have issues - just like some of us have mentioned.
Clean GO driver package supported by Neo for sure will be embraced by the community.
@technige / any news on the native go driver yet ? the hybrid seabolt / + gopkg is seriously painful. It's really letting down Neo4J for us.
Sorry, no. There is nothing concrete on the roadmap right now - there is simply a desire to do this at some point in the future. I'm afraid there is unlikely to be any progress on this in 2019 at least.
oh, that's a pity. Do you guys recommend alternative driver set for Go ? other than the one that uses seabolt ?
Currently there is the HTTP interface that a wrapper could be built around, then there is the unmaintained community driver. Sadly if the Go community wants a solid Neo4j Go driver we'll have to do it ourselves.
@MattJBrowning / Indeed I think your correct that it's DIY time ; we have production system using Go + Seabolt ; we upgrading seabolt + godriver from Neo4j = we ended up having to roll back driver version / it was not a pretty experience. I wish I has told @jim.webber face to face how I felt about this part at the Neo4J event the other week :-)
Maybe Neo4J could sponsor one of the advance Opensource projects to bring this on as an official recommend route for GO.
We're always listening @jeremy.
How would we organise a sponsored (as in with money) OSS working group to deliver an idiomatic Go driver?
If we could put together a solid plan, I'm confident we could get Neo4j to support it.
Hi @jim.webber / somehow I missed you message / let me followup and make a proposal.
How's that proposal going? The seabolt driver is a right pain to work with using Go, and I don't want to have to throw away Neo4J and replace it with something else since it is the most suited Graph database for our use case, but without a decent native idiomatic Go driver that uses contexts properly it is just not fit for our developers to use.
Closing this, since we've had a Seabolt-free, native Go driver for a while now 