why is it a disaster? can you describe one such disaster scenario? I've been using this strategy with success - just use UUID/SQUUID no need for tempid

a client could deliberate generate a uuid collision and overwrite something

Obviously you check against that. Never trust any data from your client. But other than that..? What differs data like an email address from data like an id?

if you check against it, then you're not really using a uuid as a uuid. which is fine, but not what the passage in question is advocating

I'm not reading the book to say you just trust the UUID, but that you can generate the id without consulting with the backend first. So properly working code passes the checks without round trips, while there still are checks. As opposed to something like monotonically increasing ids where it's expected to get conflicts all the time, and pretty much nothing would pass without back and forth about the ids

I do not personally suggest avoiding tempids. I use them. I think they are an awesome idea and avoid all potential problems. That said, I included that section in the book because I had users whining about not wanting to use tempids…so, there ya go. The word “trust” is not meant to be a security statement, but in terms of uuid collisions, yes, you would need to make sure you’re using a GUUID to avoid those.

deliberate collisions are a security issue…but you can have that unrealated to tempids. A real production backend MUST ALWAYS verify that the UUID being written belongs to the user making the request. At that point if the users is hacking something they are only allowed to hack their own thing.

tempids make that whole process easier…because a tempid is a known new thing that can be assigned ownership.

whereas a uuid from the client has to be “existence” and “security” checked when you don’t use tempids (or a “new” marker)

tempids are great 🙂 these two lines next to each other • "The client can generate new IDs for entities without needing a server connection. • If you use GUUIDs, then they are globally unique. " read to me like it was implying that the client generated IDs can be assumed to be globally unique, which raised an eyebrow

Ok, the solution was to also add ::m/returning User . Makes sense.

I can’t find any mention of auto-dedupe in the book, but I achieved what I needed with a merge + sweep in the pre-merge hook

https://book.fulcrologic.com/#_basic_targeting https://book.fulcrologic.com/#_targeting_loads https://book.fulcrologic.com/#_targeting_return_values_from_mutation_joins

Search for the text “append-to”

it’s all over the place

Oh I see. Sorry but from my understanding “append-to” was about appending to a list of things. Thanks for the clarification.

What else would you want to append to other than a list?

a map?

Ah, you mean you want to merge. When you say append to me, I always think of lists of things, not maps.

Ok. So pre-merge is the right way to achieve this right?