-
|
Currently, edgedb uses UUIDs based on time. This could be very convenient in not having to separately add a "time" field. However, this is currently undocumented behaviour which is not fun to be relying on. Any word on whether this feature is here to stay or not? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 5 replies
-
|
No. This an implementation detail. We will consider changing it to UUID6 or UUID7 in the future. Also this implementation detail comes from using Postgres as a backend. Postgres's default btree indexes work better if object identifiers are somewhat ordered. If we add another backend that may not benefit from this feature of object ids (i.e. uses hash indexes for primary key) we can start using UUID4 or UUID8 when using that backend. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
I recently discovered Cuid2. Eric writes a lot and it ends up in various discovery queues, but I have to admit I've read a lot of his stuff but never implemented any of it, mostly because there's an impression given through the writing style that I'll never be as smart as Eric. https://github.com/paralleldrive/cuid2#comparisons That said, I get it and I don't hate it.
"Secure" or "insecure" is context dependent, so (shockingly) this opinion on Twitter lacks nuance. You can write your bank account PIN on a piece of paper and drop it on the street and there are very unlikely to be consequences. If you write your PIN on your bank card like my grandmother once did, that's a different risk profile. Databases are designed to strongly associate data, so they are always going to to be closer to Grandma's security implementation than... littering. So, to disagree slightly with @tailhook, I think this is more than an implementation detail. And in the spirit of not littering, what is the (most) correct UID algorithm for use in EdgeDB? |
Beta Was this translation helpful? Give feedback.
-
To be clear, I'm not saying that we shouldn't discuss what UUID algorithm to use. What I'm saying that application logic should not rely on the specific algorithm used (at least not yet). Whether it's okay to use this or any other algorithm of UUID generation from the point of security depends on the application. I think current one is good enough to maintain correctness and consistency of the database. So if your app doesn't expose object ids to end users it should be okay? Or do you see any problems there? I'm not sure if we can migrate to using something non-UUID-formatted like CUID2 for object identifiers in the near feature. But for user-visible things like URL's or GraphQL IDs it's common to use some prefixed hashes, slugs, or slugs + hashes, or any other kind of random or partially random identifiers depending on the exact application. CUID2 is just one option here. |
Beta Was this translation helpful? Give feedback.
-
Cool, I think it's worth discussing, but it's also out of my area of expertise. I guess I'm asking you guys to consider it internally, which it sounds like has happened at least a little.
In the implementations I am used to (admittedly very narrow), PKs leave the database all the time and are exposed to user space. I'm probably being naïve, but I don't see how it's possible to avoid this. That's where the desire for security is coming from.
So you're saying delegate the obfuscation to the the application and not rely on the database to supply an alternative PK generation scheme? And also to not allow the return of that UUID into user space? Like I said, the idea that you should hide PKs from the user is kind of foreign to me. Is there an example GraphQL implementation in EdgeDB that doesn't permit the return of the ID field? If not, and if I understand that you're arguing it should be a best practice, I would advocate documenting it. Or help me with a recipe and I'll contribute it. |
Beta Was this translation helpful? Give feedback.
-
|
I think the "hiding the id" issue is a bit overblown here. The implementation in EdgeDB uses uuidv1 with randomized node id, so guessing ids would be extremely hard. The only issue I see is that it leaks the timestamp, but I see no other issues with it. |
Beta Was this translation helpful? Give feedback.
-
|
@tjltjl There's a potential concern with using time-based UUIDs noted here: https://github.com/paralleldrive/cuid2#note-on-k-sortablesequentialmonotonically-increasing-ids I have no direct experience with it, sorry to say, but it might be something to evaluate. There has to be a powerful space or performance constraint for you to want to drop a single datetime column, especially given that improvement that provides to the user, so this concern might be particularly relevant to you. |
Beta Was this translation helpful? Give feedback.
-
|
From cuid2 README:
This is simply not true. I'm not sure what implementations they tested, but on Postgres random-looking ids have a huge impact on write performance (for b-tree indexes, which are the default) as the random nature of the id and the page-based Postgres storage means that even a relatively small Also:
This wouldn't fly in the database context where you absolutely don't want your 10 million objects |
Beta Was this translation helpful? Give feedback.
No. This an implementation detail. We will consider changing it to UUID6 or UUID7 in the future.
Also this implementation detail comes from using Postgres as a backend. Postgres's default btree indexes work better if object identifiers are somewhat ordered. If we add another backend that may not benefit from this feature of object ids (i.e. uses hash indexes for primary key) we can start using UUID4 or UUID8 when using that backend.