Refactoring: Encode / Decode Sips.types at low level about bolt_sips

[dominique-vassard]

No problem.

I'll be off for 1.5 week at least, so don't expect a PR soon :)

[dominique-vassard]

done :)

[dominique-vassard]

Regarding conn and bolt_version.
Touching conn appears to be a bad idea as it implies massive changes for the least.
Storing it at a lower level (in the DBConnection state) seems a better idea, it's more focused and it allows to access this value in the dbconnection callbacks such as handle_begin, handle_rollback, etc. Which is pretty nice as Bolt V3 introduces special message for transaction (BEGIN, COMMIT, ROLLBACK) and invalidates the usage of "BEGIN/COMMIT/ROLLBACK" in cypher queries.

[florinpatrascu]

Storing it at a lower level (in the DBConnection state)

I thought about this too, but then for the bolt+routing we'll first have to connect before starting a pool of connections, check the server version and decide the routing strategy only after we have the server version. Storing it in the DBC state is probably not the ideal way, when recalculating the routes?! Not sure yet.

[dominique-vassard]

I don't know, I didn't look deep enough in bolt+routing to understand exactly how it works.
but the state which I update is one used in Bolt.Sips.Protocol then it's not the one where pool is stored.
In fact there was only sock in it, now it contains %ConnData{sock: sock, bolt_version: 1}. so I imagine that adding a routes key is manageable.

I'm not 100% sure but I don't think there will be problem as only one connection is made and the first message exchanged with the server is the handshake which contained its preferred bolt version. After that, messing with the routes won't change the bolt version.

[florinpatrascu]

oh I misunderstood what you meant by DBConnection state, sorry 👍