support multiple couches

[dch]

It would be cleaner to support multiple couch instances - for example if setting up replication or otherwise talking to more than one instance, a different user/password/host/protocol would be useful.

[norbu09]

how would the config look like for that? I do see how it is useful though. Not quite sure how to put it into the standard elixir config format.

[robramsaynz]

There should probably be some way of setting this, (especially useful for testing), but I don't really need it at the moment. In situations like this I expect an object holding state, rather than a config:

doc = %{a: "a", b: "b"}
remote_db = Couch.Client.new(url: "localhost:6984")
{:ok, res} = remote_db.put("db_name", doc)
{:ok, doc} = remote_db.get("db_name", res[:id])
# ...

I also expect after I've used Ecto a bit more I'll have opinions on how to structure interactions with couchex. I'd like to plug it into Ecto if possible at some point, but will get Phoenix going first before (probably meta-)programming adaptors in Elixir.

[robramsaynz]

I had a quick poke around in IEx trying to get functions to work from structs (I recall seeing this used elsewhere), but couldn't get it going. This was the closest I got:

defmodule TT do
  def qq(x) do
    IO.puts("<#{x}>")
  end

  defstruct [a: "a", b: &TT.qq/1]
end

tt = %TT{}
tt.b.(1) # works
tt.b(1) # fails

[polymetis]

Are we talking about something like this https://youtu.be/Af-gTdlQoUM?t=3755

Or are we more talking using an Agent in this case?

[norbu09]

This would allow for a config like this:

config :couchex,
  host: "127.0.0.1",
  port: 5984

config :backup_couch,
  host: "127.0.0.1",
  port: 5985

[norbu09]

Actually, that would be nice but it does not work yet. Need to think about a way to pass in the current couch to talk to in a nice and easy way. I guess it is time to re-write it as a GenServer

[dch]

I've got a fork that moves the config into mix.exs which can then be overridden cleanly in umbrella projects in their config.exs or via environment variables. This will be enough for our immediate needs.

I'd skip a Gen* for this, all the work can be done in the calling process anyway, we should have almost no state apart from a /_session key, and any hard work should not be done in the main GenServer anyway as it would easily block on e.g. view builds.

Aside from ensuring we can pipe easily, I quite like the approach of connecting to the DB (aka confirm it's a couch we are talking to GET /, then GET /_session for a token. Then any call to Couchex simply provides a map (separated config elements) or a string url like https://lolcat:5984/.