Dev instruction problems about xeus-sql HOT 8 CLOSED

Ok, got it running: by also removing the --disable-new-dtags flag:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 09bc890..e703ac9 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -116,7 +116,7 @@ set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib:${CMAKE_INSTALL_PREFIX}/${C
 # E.g. without this option libpq fails to be loaded by libsoci_postgresql, which is loaded
 # by libsoci_core, which is loaded by us.
 # source: https://github.com/chenxiaolong/DualBootPatcher/pull/548
-set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,--disable-new-dtags")
+set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl")

I copied the kernel spec to my virtualenv which hosts my jupyter lab, restarted, created a new notebook with the xsql kernel and with %LOAD postgresql dbname=bi_dwh I got it running, nice :-)

(Now running into the problem that the soci sessions seems to error because it does not understand postgresql ENUM data types, but thats a different problem :-))

from xeus-sql.

Regarding the C++14 error, are you running this on an OSX?
And thanks for the fix, will try it right away in our CI :) haven't thought about it

But this failed then in make:

I don't think this was the problem because it only showed a few warnings... I'll fix it now.
If you can reproduce the problem again I'd be interested in the complete log, please.

Hum!

(Now running into the problem that the soci sessions seems to error because it does not understand postgresql ENUM data types, but thats a different problem :-))

Could you paste the error here? Or in a new issue?
I encountered a problem with NULL types while doing some tests before, but I didn't fix it yet. It doesn't seem to be a problem with my side, but with SOCI. I'll probably open an issue there.

Thanks for testing so early! :)
Out of curiosity, how did you find out about the project?

from xeus-sql.

I just saw the error with the types now.
It's only happening in clang, apparently. Thanks for the catch! Will also have a look on them now =)

from xeus-sql.

Actually it's just a warning, not super straightforward to fix it, will open an issue for it, thanks again for opening the issue
The OSX issue was fixed by #10
Soon we should have a conda-forge package =)

from xeus-sql.

Error re ENUM:

Error: unknown data type with typelem: 26976010 for colNum: 36 with name: yyyy_column while executing "select * from os_dim.xxxx limit 10".

The table contains a column which is an ENUM, similar to this (untested):

CREATE TYPE public.enum_name AS ENUM ('aaaa','bbbb');
CREATE TABLE public.test AS (
SELECT 
'aaaa' :: public.enum_name as enum_col,
1 as int_col,
'blabla' as text_col
);

It also seems that there is still something wrong, I don't get any output, only the column names:

Out of curiosity, how did you find out about the project?

I searched for SQL notebook, saw the sqlite kernel, followed it to github and snooped around... More or less on a hunch of "if there is a sqlite kernel, why not a generic sql kernel"... :-)

(my dream: a kernel for each database I have access to as defined in my jetbrains editor, so I don't have to remember to delete the connection string/PW in the notebook before converting to html/pdf)

from xeus-sql.

Seems soci is also not able to take arrays: SOCI/soci#776 :-(

from xeus-sql.

It also seems that there is still something wrong, I don't get any output, only the column names:

Isn't it right? It should show one value, bla because you asked for 1?

(my dream: a kernel for each database I have access to as defined in my jetbrains editor, so I don't have to remember to delete the connection string/PW in the notebook before converting to html/pdf)

Hmmm idk how your environment works, but if you make different environments, you can have different SOCI implementations. You know? Like one with postgres, another with SQLite...

I searched for SQL notebook, saw the sqlite kernel, followed it to github and snooped around... More or less on a hunch of "if there is a sqlite kernel, why not a generic sql kernel"... :-)

hehe awesome! :)

from xeus-sql.

Select 1 as bla should give a table:

+---+
|bla|
+---+
|1  |
+---+

Hmmm idk how your environment works, but if you make different environments, you can have different SOCI implementations. You know? Like one with postgres, another with SQLite...

I have like 5 different postgresql DBs I want to connect to :-) So it's more about to pass in the connection string in the kernel config instead of writing it in the first line. E.g. I'm still using https://github.com/Cadair/jupyter_environment_kernels for my virtualenvs and I can imagine adding something similar to add multiple DB connection kernels... Or some script to generate kernel configs in the virtualenv which hosts my jupyter lab :-)

from xeus-sql.