All generators generate the same code

[jhoffman-tl]

Things to check first

• I have searched the existing issues and didn't find my bug already reported there

• I have checked that my bug is still present in the latest release

Sqlacodegen version

3.0.0 with pgvector support

SQLAlchemy version

2.0.37

RDBMS vendor

PostgreSQL

What happened?

Each of the following commands generates the same model code.

uv run sqlacodegen --schemas <schema>  --generator=tables  <db_url>
uv run sqlacodegen --schemas <schema>  --generator=declarative  <db_url>
uv run sqlacodegen --schemas <schema>  --generator=sqlmodels  <db_url>
uv run sqlacodegen --schemas <schema>  --generator=dataclasses  <db_url>

I see Using pgvector 0.3.6 printed too if that's helpful information.

Database schema for reproducing the bug

The schema + tables were created with dbt if that is a helpful data point

CREATE TABLE dbt_dev_group_members (
    id character varying,
    group_id character varying,
    microsoft_graph_group_id character varying,
    user_id character varying,
    microsoft_graph_user_id character varying,
    user_given_name character varying,
    user_surname character varying,
    user_email character varying,
    user_display_name character varying,
    group_display_name character varying,
    group_description character varying
);


CREATE TABLE dbt_dev_groups (
    id character varying,
    microsoft_graph_group_id character varying,
    display_name character varying,
    description character varying
);


CREATE TABLE dbt_dev_users (
    id character varying,
    microsoft_graph_user_id character varying,
    display_name character varying,
    given_name character varying,
    surname character varying,
    email character varying
);

[sheinbergon]

@treeline-jacob so, it's something with the provided schema, it's the fact that dbt doesn't generate primary keys.
If you go ahead and configure primary keys on your generated tables in postgresql, sqlacodegen will work as expected.

You should use dbt contracts to define primary keys, as described here - https://discourse.getdbt.com/t/can-dbt-indicate-primary-keys/11064/2

@agronholm while I have no opinion about tables with or without primary keys, we should probaly not generate broken bindings in case PK is absent. WDYT?

[sheinbergon]

@agronholm would still love to hear you out on this issue

[agronholm]

WDYM by "broken bindings"?

[sheinbergon]

The resulting code in this case are table bindings with the wrong import statements, regardless of what generator is selected

[agronholm]

In that case, yes, that's definitely a problem.

[sheinbergon]

Great. Do we want to support tables without PK, in your opinion?