(Q&A) steps towards releasing Bolt.Sips version 1.3, stable

[florinpatrascu]

@dominique-vassard - we use the -rc postfix mostly to stay close to the db_connection's own status. Now that db_connection is stable, should we too drop the -rc? What do you think?

[dominique-vassard]

There's only one bug with Duration to fix. nanoseconds are not well treated right now:

• Large amount of nanoseconds (> 999_999_999) should be converted to seconds + nanoseconds
• nanoseconds formating is erroneous This will be quickly fixed, you'll have the PR on monday (I don't have available time today).

Regarding json encoding, we could provide some default jason/poison encoder. It could be helpful for those who just want to send back database data via their endpoint without having to develop their own formating module. I agree that, conceptually, it is not part of the driver but it eases its use. Either we can add it, it's as simple as this:

defmodule Bolt.Sips.TypesJasonEncoding do
  alias Bolt.Sips.Types

  defimpl Jason.Encoder, for: Types.DateTimeWithTZOffset do
    def encode(struct, opts) do
      {:ok, dt} = Types.DateTimeWithTZOffset.format_param(struct)
      Jason.Encode.string(dt, opts)
    end
  end

  defimpl Jason.Encoder, for: Types.TimeWithTZOffset do
    def encode(struct, opts) do
      {:ok, dt} = Types.TimeWithTZOffset.format_param(struct)
      Jason.Encode.string(dt, opts)
    end
  end

  defimpl Jason.Encoder, for: Types.Duration do
    def encode(struct, opts) do
      {:ok, dt} = Types.Duration.format_param(struct)
      Jason.Encode.string(dt, opts)
    end
  end

  defimpl Jason.Encoder, for: Types.Point do
    def encode(struct, opts) do
      {:ok, pt} = Types.Point.format_param(struct)
      Jason.Encode.map(pt, opts)
    end
  end
end

• some config in order to support Poison and Jason which have the same protocol implementation. OR add some docs about this particular problem.

But for the release, it can b shipped as soon as the first point is fixed.

[florinpatrascu]

it all makes sense, totally. Tho' for the Bolt.Sips.TypesJasonEncoding, I'd opt for a slightly more generic/cleaner naming convention, i.e.: Bolt.Sips.TypesEncoder, a protocol, for example:

defprotocol Bolt.Sips.TypesEncoder do
  @fallback_to_any true

  def encode(value, opts)
end

something like that. Them we can provide specialized encoders (using a user json library config param), as you very well described above. Or graphql, in the future ;)

[Gollor]

@dominique-vassard I like this approach. It looks pretty well and as I get it still allows the user to override Jason.Encoder implementation and use his own methods.

[dominique-vassard]

it all makes sense, totally. Tho' for the Bolt.Sips.TypesJasonEncoding, I'd opt for a slightly more generic/cleaner naming convention, i.e.: Bolt.Sips.TypesEncoder, a protocol, for example:

defprotocol Bolt.Sips.TypesEncoder do
  @fallback_to_any true

  def encode(value, opts)
end

something like that. Them we can provide specialized encoders (using a user json library config param), as you very well described above. Or graphql, in the future ;)

A generic solution is quite appealing, especially if we consider covering multiple special graph formats (graphML, gexf, cytoscape-schaped data, dot, etc.). For this purpose, a Protocol is the de facto solution.

However, regarding json, it is slightly different if we want a seamless implementation in elixir context. The best example is Phoenix: with the protocol solution, you have to, at some point, call Bolt.Sips.TypesEncoder.encode on your query result. Having some derivations of Poison/Jason protocol allows the user to do, well, nothing :) because call to encoding function will be automatic, which is pretty nice. I've tested it this afternoon and the possibility to treat Neo4j's data as easy as postgres data is great.

Then, we could get the best of both worlds by:

• implementing a protocol as you mentioned
• add a protocol derivation / macro / what-could-fit to ease furthermore the encoding in specific context

It seems to be more complicated than I thought on first sight, so maybe it's a good idea to release the 1.2 and to work on this feature next, what do you think?

[florinpatrascu]

maybe it's a good idea to release the 1.2 and to work on this feature next, what do you think?

this indeed makes the most sense to me.

[dominique-vassard]

Hi, I've pushed a draft request for some proposals

[dominique-vassard]

We're ok for release 1.3?

[florinpatrascu]

Yes, I believe so. It’s just that I’m away from computer and can’t publish right now. The merge was done from my mobile.

[florinpatrascu]

releasing 1.3.0. Thank you so much!

[florinpatrascu]

1.3.0@Hex.pm, finally :))