Open greguintow opened 4 years ago
Hi @greguintow
I have marked this is a feature request but just for fyi we support CUIDs(https://github.com/ericelliott/cuid) in the schema via @default(cuid())
so maybe you can use them for your use case.
Humm, so shortid might not be necessary, because you could implement a slug()
function that would execute cuid.slug() instead of analyzing another id generator.
@greguintow That is not configurable yet.
@pantharshit00 Yes, of course, I'm saying that would be easier to implement a slug function with cuid.slug()
than analyze another id generator.
ShortId has been deprecated in favor of https://github.com/ai/nanoid/ This is currently low in our list of priorities as we want first to close gaps leading users to resort to SQL, so I wouldn't expect this to be picked up anytime soon.
+1 for working on higher priority stuff, but nanoid()
would be nice at some point in the future :)
I was hoping nanoid()
would be available, or maybe a way to import and use our own method for creating default values. Happy to see this is being discussed though.
Oh, it appears Prisma does have an implementation of cuid available: https://www.prisma.io/docs/reference/api-reference/prisma-schema-reference#cuid
Additionally, cuid
contains the date/time it is generated at, which you may not want. I am looking at using slugid with uuidv4, but if not, I would likely be using nanoid or shortid.
While I think cuid.slug()
would be a nice (probably small?) addition, the slugid is a nice suggestion which probably works for my usecase
is there a nanoid
tracking issue? this would be really nice to have as we're also manually having to add this on every insert
A possible workaround if you are using Postgres. If you mark the id as id String @id @default(dbgenerated("nanoid()")) @db.VarChar(11)
in your schema, generate a migration without applying it (npx prisma migrate dev --create-only
), and add a nanoid function to your database at the top of your new migration (see code at https://github.com/Jakeii/nanoid-postgres for the Postgres function), you should be able to have nanoids. Just make sure that the default length in your Postgres nanoid function matches the size defined in your schema. In my case, I changed the default to be 11. Lastly, apply the migration and generate the Prisma client.
I wouldn't recommend storing nanoids in postgres as UUIDs are stored more efficiently. I think a better solution would be to use https://github.com/oculus42/short-uuid or the previously mentioned https://github.com/taskcluster/slugid to translate between uuid and user-friendly IDs at the app layer.
Nanoid is going to be available in 4.9.0. Would it be enough to close this issue?
Has this been integrated now that we're on 4.16.x
?
Problem
There are times we wanna display friendly links to the user,
Solution
Shortid provides an id of 7 to 14 letters that is less than half of the uuid. ShortId repository So this would be interesting to add in the default directive.