Open jeffrey-computers opened 7 months ago
I agree. Primary keys should not be restricted in this manner. Additionally, supporting composite primary keys would allow for more flexible indexing paradigms.
However, this may not be a trivial change. The code generator adheres to the OpenCRUD spec, which currently only supports primary keys of type ID
(essentially a string) and does not support composite primary keys (maybe it does, am not completely familiar with the spec)
Describe the bug TypeORM
@PrimaryColumn
supports fields with an arbitrary name, but Squid's codegen only supports a PrimaryColumn named 'id'. If an 'id' value is not included in the schema, then it is added automatically.This means code comments are required to explain what the entity's
id
value is, rather than semantic field names. As is evidenced in your own example project!To Reproduce Create a
schema.graphql
file like:Codegen automatically creates a
@PrimaryColumn_()
ofid
. The intended primary column issomeUniqueIdentifier
Expected behavior
ID!
should be used for TypeORM'sPrimaryColumn
instead of id.id
field should be created unless anID!
is missing.i.e. the above example Should yield: