Database manager: Add CHAR type. I'm using MariaDB
Knex() as standard would create a varchar of same length as standard.
To force a char type the "specifictype" property needs to be added.
I dont think it is supported currently but should be an easy modification.
Maybe a checkbox "fixed" leading to specifictype being applied
What do you want to store in a CHAR? And why it has to be char?
ULID 26 characters
you mean uuid? There is an uuid data type you know
ULID, UUID alternative that has the first part time-based so it's easier to index on databases. There's also UUIDv7 with the same goal, but ULID is shorter for usage in URLs. What do you think?
UUIDs were designed to make it challenging to easily guess records, such as those found at paths like /user/af44d4f0-92b6-475f-8902-a2c06a6f938a. Their effectiveness comes from their considerable length, randomness, and unpredictability, which helps to prevent users from scraping or deducing other records. This makes UUIDs a valuable tool for obscuring sensitive data identifiers.
Nevertheless, UUID version 4 (UUIDv4) has the limitation of not being sortable, which can pose difficulties in certain applications. This issue has been addressed by UUID version 7 (UUIDv7), which introduces sortability. Another drawback of UUIDs is their length: the 36-character hexadecimal string, including dashes, can slow down indexing operations due to its size.
To tackle some of these problems, ULID (Universally Unique Lexicographically Sortable Identifier) has been developed. ULIDs use a shorter 26-character Base32 string and do not include dashes, making them more convenient to copy and paste. This shorter format also contributes to faster indexing and easier handling.
Despite these improvements, neither UUIDs nor ULIDs inherently provide security. Real protection comes from implementing proper authorization checks, rather than relying solely on the complexity or obscurity of the identifier when accessing endpoints like /user/:id. Security should be enforced at the application level to ensure that users can only access data they are permitted to see.
In my experience testing UUIDv7 for record indexing, I found that sequential IDs are generally more practical for internal server-side indexing due to their simplicity and efficiency. On the other hand, UUIDs or ULIDs are better suited for external client-side use, where obscurity and uniqueness are more important. This approach offers a balance between security through obscurity and operational efficiency by combining UUIDv4 or UUIDv7 with monotonicity. My preferred solution involves using a sequential main index column alongside an additional column for the UUID.
It is also important to highlight that ULID is a community-driven standard, whereas UUIDs follow the formal RFC 9562 specification. This distinction may influence the choice between the two depending on the requirements of a project or system.
1 Like
Was nice to see uuid7 support added to Wappler recently.
Are you saying Wappler added UUIDv7 support?
Yes, my custom UUID7 extension got benched before i got around to releasing it! 
3 Likes