No, consider them internal

so, it is better to have some uuid or int id which can be exposed?

yes. lookup refs can be used everywhere an eid can, e.g. [:person/id #uuid "asdf-asdf-asdf-asdf"]

They are not guaranteed to be unchanging. So there should be no long-lived weakly-referenced entity ids in your system (eg in a url, or in a json blob stored somewhere). In your example, your urls night break one day.

Using eids in short-lived contexts is ok

thanks for the explanation! i'll look into this lookup refs

eid haven't changed in practice so this may not be important practically speaking

but remember that if you re-create a database in some way other than restoring (i.e. re-inserting datoms), you won't have control over eids

yeah, that's what i noticed reading the docs on Identity and Uniqueness, thanks for confirming

it works just like an identity column in a relational database configured auto increment

@U06F82LES what will happen if you use [:person/id #uuid "....."] and the string is not a valid UUID?

my argument for using strings for UUID types has been that I don't want to manually convert to an UUID object and have to catch the exception that java throws if it's invalid and return a 404 instead of a 500 in my web servers

but maybe the #uuid tag behaves differently

@U0MKRS1FX you'll get a reader exception

but yeah you'd have to catch the exception manually I think if you care

ah, I'll stick to strings, then. I'm lazy 🙂

thanks for the info!