bobgen: Tables without primary keys are always views

[sweigert]

For the following schema, bobgen will always generate the model for table_with_no_primary_key as a view:

CREATE TABLE table_with_no_primary_key (
  id UUID,
  id2 UUID
);

ALTER TABLE table_with_no_primary_key ADD CONSTRAINT unique_rows UNIQUE (id, id2);

(note, that the unique constraint is not necessary for this minimal example)

Results in:

// TableWithNoPrimaryKeys contains methods to work with the table_with_no_primary_key view
var TableWithNoPrimaryKeys = psql.NewViewx[*TableWithNoPrimaryKey, TableWithNoPrimaryKeySlice]("", "table_with_no_primary_key")

This is because RelIsView assumes that a table with no primary keys is always a view.

[stephenafamo]

Yes. This is on purpose.
Primary keys are core to the operation of the ORM, updates, deletes, e.t.c. cannot work properly without a primary key.

Calling tables without primary keys "Views" is because naming is hard 😅
In a similar vein, if a driver ever reported that a view has primary keys, it will be treated as its own table.

[sweigert]

I understand and it seems reasonable. I stumbled upon this problem because I had a table without a primary key but with a unique key constraint (which kind of worked like a primary key). I fixed the table to have a primary key now and everything is good again.

It just took me a while until I understood why I am not able to use the generated model the way I wanted to use it but I also don't know how to make this more transparent to the user of the lib.

Thanks!

[stephenafamo]

This is an interesting point.

In many cases, a unique constraint can fill in for a primary key since what is really needed is the uniqueness of rows.

I'll add this as a potential future enhancement.