Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] - Query result from scratchpad displays wrong columns #316

Open
UrbanMarco opened this issue Jan 9, 2025 · 2 comments
Open

[BUG] - Query result from scratchpad displays wrong columns #316

UrbanMarco opened this issue Jan 9, 2025 · 2 comments
Labels
bug Something isn't working

Comments

@UrbanMarco
Copy link

Describe the bug
I have the following query in the scratchpad

select s.id, s.state, p.id
from subscription.subscriptions s, product.plans p
where s.plan_id = p.id
and is_plan_available(p.activated_at, p.retired_at) = true
order by p.id;

when I run it, I am expecting to see a table with 3 columns: on the left the subscription IDs, in the middle the state of the subscription and on the right the plan ID.

However, WhoDB displays both on the left and on the right the plan ID.

To Reproduce
As explained above

Expected behavior
Same query but directly with PSQL

  id  | state |  id
------+-------+-------
 3102 |    16 |  5896
 2982 |    12 |  5896
 2910 |    16 |  5896
 2916 |    16 |  5896
 2920 |    16 |  5896

Screenshots
image

Additional context
Self-hosted version 0.45 with the following docker-compose file

version: "3.8"
services:
  whodb:
    image: clidey/whodb
    volumes:
      - ./sample.db:/db/sample.db
    # environment:
    #   WHODB_OLLAMA_HOST:YOUR_OLLAMA_HOST
    #   WHODB_OLLAMA_PORT:YOUR_OLLAMA_PORT
    ports:
      - "8081:8080"
@UrbanMarco UrbanMarco added the bug Something isn't working label Jan 9, 2025
@hkdeman
Copy link
Contributor

hkdeman commented Jan 9, 2025

Thank you for the great observation! This seems definitely an important issue. We will push out a fix for this soon. Will update this thread.

Meanwhile, I believe you could use SQL alias to get over this (incase it is a blocker).

@UrbanMarco
Copy link
Author

Meanwhile, I believe you could use SQL alias to get over this (incase it is a blocker).

What do you mean? For the moment I went back to PSQL

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants