search

mschae / boltex

Elixir driver for the neo4j bolt protocol
Other
29 stars 6 forks source link

any big structural changes planned for what's returned by Boltex.Bolt.run_statement/4? #6

Closed florinpatrascu closed 8 years ago

florinpatrascu commented 8 years ago

Hi Michael - I am using a fork of your project in https://github.com/florinpatrascu/bolt_sips, and I depend on the data structures returned now from Boltex.Bolt.run_statement/4. Are you planning any big changes about how the data will be returned from Bolt? Ideally I'd like to use your driver directly, and not ending up maintaining my own fork. Thank you.

mschae commented 8 years ago

Hey @florinpatrascu,

since this is very alpha API changes are unfortunately likely. However right now I don't plan to change run_statement.

Note that I am in the process of implementing DBConnection, which would serve as a replacement for bolt_sips: https://github.com/mschae/boltex/tree/add-dbconnection

DBConnection is a more suitable alternative to a plain GenServer/poolboy based connection pooling. It offers different pool options, encoding/decoding in the calling process, etc. The branch is very much WIP right now but I hope you can see where I'm headed with this.

Hope that helps. Cheers

florinpatrascu commented 8 years ago

Thank you for your comment. I believe It will be fine, from my perspective, if Boltex will continue to return the unpacked messages received from the server; the way you do it now. That's what I am consuming in my own driver; I am simply using Boltex as a "translator", for now and as you probably saw, convert its decoded Bolt responses to higher level structures that make sense to a Neo4j developer, i.e. Node, Path, Rels etc.

Regarding the DBConnection, I too agree it is better than a standard Poolboy/GenServer implementation. In my case I had to use a pool of some sort until Boltex was ready to provide one, hence quickly putting together the current implementation, in bolt_sips. Thanks again!

mschae commented 8 years ago

Cool yeah I am happy to see such an early adoption of Boltex, so feel free to keep using it.

I always strive to keep APIs intact so I doubt it will change much. If so I will let you know and provide a migration strategy. I definitely don't intend to do further "unpacking" of messages. That will be taken care of by a higher level implementation, of which bolt_sips can be one (I was thinking about ways to make it work with Ecto, as I am already using Ecto Changesets with Neo4j. Might be too different in terms of query language and overall philosophy tho.

Totally cool to use your own pool implementation until mine is ready, which is hopefully soon (I will start using the dbconnection branch in production in on of our apps, soon, to see if it all works out). The API will be very straightforward and documented.

Thanks again and let me know if there is anything else you need.

Oh and I was encoding large integers wrong! Fixed in this commit: https://github.com/mschae/boltex/commit/cbdc163781ae9a711a7d7328966bb7bd985d73fe Let me know if you would like a release.

florinpatrascu commented 8 years ago

I saw the Integer related change, and imported the changes in the fork the moment you fixed it. Thanks again for the reminder and for making Boltex available!!