You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(sorry for making a bunch of new issues and not doing anything to solve them yet. I'll get there, I promise)
UUIDs are commonly used as primary keys in large database tables, providing a dense, globally-unique, and opaque identification system. Currently, Crecto "supports" UUID values by treating them like normal strings.
However, a large advantage of UUIDs is that they are simple 128-bit values that can be stored and utilized in their binary form. This can be noticeably more performant than the string representation, especially as tales grow in size.
Crystal's UUID type already uses the binary data for comparison, so implementing this seems like it could just be a matter of adding it as a valid field type and constructing the type properly.
In the last case, where the database does not support the UUID type natively, I would imagine Crecto could just fallback to just storing the data either as a 16-byte binary blob or integer type, either of which would still provide a benefit over storing them as strings.
The text was updated successfully, but these errors were encountered:
(sorry for making a bunch of new issues and not doing anything to solve them yet. I'll get there, I promise)
UUIDs are commonly used as primary keys in large database tables, providing a dense, globally-unique, and opaque identification system. Currently, Crecto "supports" UUID values by treating them like normal strings.
However, a large advantage of UUIDs is that they are simple 128-bit values that can be stored and utilized in their binary form. This can be noticeably more performant than the string representation, especially as tales grow in size.
Crystal's UUID type already uses the binary data for comparison, so implementing this seems like it could just be a matter of adding it as a valid field type and constructing the type properly.
In terms of database support, Postgres has had native support for UUID types since at least 8.3, and MySQL introduced the datatype in 8.0, but SQLite does not natively support them as a datatype.
In the last case, where the database does not support the UUID type natively, I would imagine Crecto could just fallback to just storing the data either as a 16-byte binary blob or integer type, either of which would still provide a benefit over storing them as strings.
The text was updated successfully, but these errors were encountered: