agronholm
Add force_class option
The current logic is that, if a table has no primary key, it doesn't use the declarative class generator. However, sqlite has the hidden rowid column which acts as a primary key. For this reason, I want to generate a dataclass and then add rowid as the primary key so that I get all the nice type safety of a dataclass. There are probably also other use cases for ignoring this rule.
Thus, this PR adds a new option called force_class that will generate a dataclass even if there is no obvious primary key.
The problem is that ORM classes don't function at all without primary keys. It won't work, period.
If there is a "hidden" column, the ORM needs to know about it. Not declaring a primary key won't work.
I think my logic in making this pull request was that you get the sqlacodegen to generate all of the columns and put it into a class, and then you manually modify the code to add the hidden rowid column as a primary key. I could have modified the generator to just add rowid using a flag, but that would have been an SQLite-specific change and thought that this was more generic.
I think my logic in making this pull request was that you get the
sqlacodegento generate all of the columns and put it into a class, and then you manually modify the code to add the hiddenrowidcolumn as a primary key. I could have modified the generator to just addrowidusing a flag, but that would have been an SQLite-specific change and thought that this was more generic.
Doing something manual post generation to compansate for a lack of a pre-requisiste is out of scope. We are generally moving in different direction and would opt out all non-table generators for tables without PK
Right but the pre-requisite (a primary key), is actually there, it's just not being detected. It's an SQLite idiosyncrasy.
If you want to remove the manual step then I can just make an SQLite-specific code path that does it for you. I just didn't think that was the most elegant.