stablekernel
Postgres UUID type in models
Hi! Sorry if I missed this part in the docs. Is it possible to have a field in my models which would map to a UUID column type in the database? ManagedPropertyType does not seem to have it.
There isn't currently support for UUID. I believe the holdup was on deciding whether or not there should be a UUID type or a String and having to specify @Column(databaseType: ManagedType.uuid).
Can you consider reopening/adding this? UUIDs are preferable for primary keys in several instances. Alternatively, if there was an option to specify a custom Postgres data type that would work too. But it currently doesn't seem possible at all, as only the types specified in ManagedType can be used...
Is there a workaround at the moment, except manually storing UUIDs in a String column? I imagine this has serious performance penalties.
Is there a workaround at the moment, except manually storing UUIDs in a String column? I imagine this has serious performance penalties.
To be honest using uuid instead of auto increment has performance impact.
Can you explain your use case @hero101111 ?
A UUID can be a fire and forget regarding database insertions, using an autoincrement integer requires submitting the request and then querying it back again to get the ID.
It's also just in general a common practise to use UUID primary keys in postgres (depending who you ask).
I think @hero101111 's point was that using a UUID in a string data type instead of the natively supported UUID type adds unnecessary performance penalties, despite the database fully supporting the intended data type.
A UUID can be a fire and forget regarding database insertions, using an autoincrement integer requires submitting the request and then querying it back again to get the ID.
Yed that would be a use case but if I have such a problem with slow inserts I would rather write in a different database.
It's also just in general a common practise to use UUID primary keys in postgres (depending who you ask).
I was one of those people. It is really bad as you have a significant slowdown compared to big int. Now if I want to hide the key itself from the end user I will make additional uuid column use it to query a resorse by it but join through the primary key.
I think @hero101111 's point was that using a UUID in a string data type instead of the natively supported UUID type adds unnecessary performance penalties, despite the database fully supporting the intended data type.
I am not sure what his point is as I never heard it so I would not assume. Depending on the use case different approaches could be taken so you could use uuid.
Is it the case that Aqueduct is opinionated against implementing the UUID data type? I'd like to do a PR to implement this..
@rageycomma I think if you implement and write tests for it @joeconwaystk will be glad to merge it.
Yes, would be happy for someone to implement a UUID data type. The more data types exposed to the ORM the better.