Connect Elixir to Couchbase (Couchie outdated)

big-data
databases
Tags: #<Tag:0x00007f1143558880> #<Tag:0x00007f11435586c8>

#1

I found a topic about NOSQL-Database of 2016. Since then nothing new. We have a Couchbase with tons of reporting data exctracted out of our RDBMS-live system.

I will give Phoenix a try and build up a little reporting-system, using this data from Couchbase. Trying to use the couchie-lib I got a warning during compilation and errors trying to establish a connection. Libcouchbase is installed and it works with other languages like ruby.

Can somebody tell me how to connect to Couchbase without the REST-Api? Or which NOSQL-Databases do you use for heavy data in connection with Elixir?

Thanks!


#2

Really no one using NOSQL with elixir, who could tell about his experiences? I am open for good ideas who might lead to a change of the database It was the N1SQL-Language we liked the most with Couchbase. Map-Reduce is a really ugly thing in my opinion.


#3

I had tried https://github.com/chitika/cberl but for our needs we required N1QL to work and the n1ql queries kept crashing elixir thru the nifs. We ultimately ended up using the REST API’s. Unfortunately I haven’t been able to open source the client, but it runs well for our relatively low data requirements.

With Couchbase’s websocket connection you can get a change feed going pretty well too. But the bulk of data operations is done over REST in our case.


#4

I use some NoSQL things, but that is ‘through’ PostgreSQL, which has NoSQL table support in it. ^.^;


#5

Ok, I will try it over the N1QL-API. @gdub01, do you know if there is a special API for document manipulation? I can’t find it in the docs.

@OvermindDL1: are you happy with PostgreSQL? I didnt’ like the authorization-procedures and the documentation in connection with this topic.

An Elixir adapter using the libcouchbase (again) would be great. Unfortunately my knowledge of Elixir is not so experienced yet to do it on my own. Maybe someone can compensate this gap in the near future.

Thank you for your input so far.


#6

I love it, been using it for many years. What authorization procedures and documentation though?


#7

As far as I remember the user management ist spreaded over config files and additionally user granting in the database. The whole ecosystem of the database was not mine. I always prefered MySQL (and later MariaDB). But I love the approach of the NoSQL Databases. Especially Couchbase with it’s N1SQL query language.


#8

I’m not sure what that is referencing at all actually…

PostgreSQL users exist in a table, fully editable via SQL and all? o.O

As do schema definitions, tables, enumerations, custom types, FDW, etc… Everything is accessible via SQL in it, as long as you have the permissions. ^.^

MySQL/MariaDB are both lacking a lot of features that PostgreSQL has, there is never ever a reason to chose them over PostgreSQL.

Never heard of it? What’s it like? Hmm, a quick googling shows that it is a restricted set of normal SQL, so why not just use normal SQL then as it ‘looks’ like any valid N1SQL is also valid SQL (swapping " for ' and a few other minor things of course)? I’m not really seeing anything it gains over normal SQL? Can you demonstrate something it can do more easily than normal SQL? I’m quite curious. :slight_smile:

Also, SQL is just one dialect that PostgreSQL supports, it has an entirely pluggable language system, there are others. :slight_smile:

In what way? You can do the same in PostgreSQL for KV storage, in addition in PostgreSQL you can add arbitrary index tables, views, materialized views, functions, and more that I’ve not seen any pure NoSQL system capable of doing?


#9

We ended up using https://developer.couchbase.com/documentation/mobile/1.5/references/sync-gateway/admin-rest-api/index.html which is the sync-gateway api… which ultimately makes change to docs on the server while ensuring the sync gateway stays in sync with the server.

However for N1QL, you have to use the couchbase server api. https://developer.couchbase.com/documentation/server/5.0/n1ql/n1ql-intro/queriesandresults.html


#10

Ok. I guess I hadn’t a full or deaper look at Posgre, giving it a real chance.

We have a lot of dependencies between tables (in production RDBMS). They are predestined for nested document objects. We prefered the Couchbase because N1SQL has a very SQL-like syntax, that most people around can read and understand easily. Not thousands of joins required.


#11

Thanks to @gdub01 I implemented Tesla yesterday. Testing today looks really good. As long as there is no library, you can fire your statements over Tesla to the API with a few lines of code:

defmodule Couchbase do
  require Logger
  use Tesla
  
  plug Tesla.Middleware.BaseUrl, Application.get_env(:testing, :couchbase_url)
  plug Tesla.Middleware.BasicAuth,
    username: Application.get_env(:testing, :couchbase_user),
    password: Application.get_env(:testing, :couchbase_pwd)
  plug Tesla.Middleware.JSON

  def query(statement, args \\ []) do
    json_input = %{statement: statement}
    |> get_args(args)
    Logger.debug("JSON-Input: #{Poison.encode!(json_input)}")
    post("/query/service", json_input)
  end

  defp get_args(input, args = [ _ | _ ]) do
    case Keyword.keyword?(args) do
      true ->
        args
        |> Enum.into(%{})
        |> Map.merge(input)
      false ->
        Map.merge(input, %{args: args})
    end
  end
  defp get_args(input, []), do: input
end