Support timescale > 1.7.5

chicco785 commented 3 years ago

Is your feature request related to a problem? Please describe.

Tests shows that there have been changes starting from timescale 2.0.2 that breaks integration with it.

Describe the solution you'd like

Support timescale > 2.0.2

Describe alternatives you've considered

Stay with 1.7.5 for the time being.

AbyssCoreInc commented 3 years ago

I have timescale extension 2.4.0 installed and I am trying to get quantumleap connect to it. I most likely have some problem in my general setup for timescaledb since I do not get any output in docker logs.

my docker-compose setup is like this:

  quantumleap:
    hostname: quantumleap
    image: orchestracities/quantumleap:latest
    container_name: fiware-quantumleap
    ports:
      - "8668:8668"
    environment:
      - POSTGRES_HOST=127.0.0.1
      - POSTGRES_PORT=5432
      - POSTGRES_DB_NAME=quantumleap
      - POSTGRES_DB_USER=quantumleap
      - POSTGRES_DB_PASS=quantumleap
      - LOGLEVEL=DEBUG
      - USE_GEOCODING=True
    networks:
      - default
    restart: always

Documentation says I should set QL_CONFIG variable with path to quantumleap YAML configuration file otherwise Crate backend will be used. I haven't been able to fins any info on how to set up that file or any examples of it. So that is one problem, but are there other potential issues connecting to the timescaledb? Only output in logs is this:

time=2021-06-01 10:13:44.831 | level=DEBUG | corr=None | from=None | srv=None | subserv=None | op=read | comp=utils.cfgreader | msg=Env variable USE_FLASK not set, using default value of: False | payload=None | thread=548652015160  | process=1

How should the problems with >1.7.5 version of timescale manifest?

chicco785 commented 3 years ago

@AbyssCoreInc as by ticket and readme.md, timescale > 1.7.5 is not currently supported

AbyssCoreInc commented 3 years ago

Do you know how the incompatibility manifests? If I have time I could see if there is anything I can do to help making it compatible.

chicco785 commented 3 years ago

some sql bombing :) but i didn't save the stack trace :( to reproduce, just set the env variable QL_DEFAULT_DB to timescale and have look in the logs.

chicco785 commented 3 years ago

@AbyssCoreInc

actually, some latest changes may have solved the issue: in PR #492 I just added a multi matrix test including new versions of timescale in it (but only for translators, issue may be exposed only in reporters), and translators tests are all good...

if you wanna play around, to set-up the dev environment and run tests:

git clone the repo
install python 3.8.5
change in deps.env ts version
run sh setup_dev_env.sh
run sh run_test.sh and see reports

github-actions[bot] commented 3 years ago

Stale issue message

orchestracities / ngsi-timeseries-api

Support timescale > 1.7.5 #482