I guess I should just get the latest created booki...
# prisma-whats-new
p
I guess I should just get the latest created booking and check what the number is and increment it?
a
Does it have to be a number?
p
no it doesnt
but needs to be unique
a
Use cuid()
m
You can use the Schema Extensions to create a CUID and apply that to the booking. A CUID is a Collision Resistant Unique Identifier, just for this purpose.
a
It's the same thing Graphcool uses to generate the unique ID's for all your nodes, types, functions, etc.
p
but does graphcool support it?
or do I need to brute force it?
do I need to send that along in a mutation or will graphcool generate it?
a
You need to do that in a function
RP hook
createBooking ->
TRANSFORM_ARGUMENT
-> uniqueId = cuid() -> save
p
ok so if I create a cuid in a function and try and save it and that number is already taken, what then? the mutation with throw an error. Then I need to retry recursively until it no longer errors?
a
you should never get the same cuid
p
how would it know that it already generated that one? does it check the mac address and timestamp?
or do I pass it the bookingId ?
a
just make the field @isUnique
p
yes I will, but if it isn't graphcool will just throw a error?
so should I recursively try in the error handling until it accepts?
a
If you really want to, yes
p
Copy code
module.exports = function (event) {    
  var cuid = require('cuid');
  
  event.data.bookingNumber = cuid();
  
  return {data: event.data};
}
just that?
a
Yes, just that
p
ok cool thanks
a
But why would you need that?
Because you'll get the same kind of id as the bookingId
which is equally unique
p
Transform argument, right?
a
yes
p
Thanks so much
😎 1
is there any way I can specify a format for this?
kinda the reason for generating a booking number is coz I dont want to use the ID
This number will go to account for invoices etc.
maybe that?
a
I guess not. You can use cuid().slug()
Well... anything shorter increases the chance of collisions
shortid has more customization options
so might be a better choice for you
m
Would it be better to create a Type specifically for the booking account, then associate the account with a User in a 1-1 relationship?
a
From what I understood, Booking is already a seperate Type, but he didn't want to use the ID for human readable communication, so another, shorter, more readable, yet still collission-safe, identifier was needed
m
Okay I see, how I interpreted it was he wanted to connect those in a has-many relationship to the user without having to use the actual user's id.
n
@Pieter the part about the cuid that makes it collision resistant is the internal counter and the encoded timestamp. that's only a fraction of the characters used for cuid
p
@nilan thanks I figured it might be something like this
The client wanted things to be super readable so I ended up using a counter and just adding the user's firstname and lastname to it. How I achieved the counter was by doing a query on
allBookings
and filtering using
last: 1
and then checking what that one's bookingNumber is, then I parse the int (after removing the user's name) and increment it. If there are no bookings in yet (new deployment) I just set it to 1. Then I take that number and add the expert name at the end and add it to
event.data
and
return {data: event.data}
I am assuming here that even if 2 bookings are created within the same second that due to it being a
transform argument
, they will run in a linear fashion. Or is it completely async?
@nilan what will happen if the booking number is already taken? seeing as its not a actuual mutation in the code but rather just returning the transform, will it just error out and not save the booking at all or what? How do I handle that error and retry?
I ended up doing a query to _allBookingsMeta with the newly generated booking number to see if there are any in the system already. If there are I increment and recheck recursively until there isn't one. This seems like brute force but my starting point is still the last booking in the database and it has the user name at the end so it's pretty rare for it to occur (or not at all if things are syncronous). Thanks for the help guys