sdegutis: the macro is for .edn files. you should use d/tempid in your code, as #db/id reader macros produce one value only

(fn new-id [] #db/id[:db.part/user] ) this would return the same value how ever many times you call it

#db/id is a convenient way to specify a one off temp-id in a data-only manner

such as in schema.edn

Hm, are the way to do restoring to DDB a bit quicker? Might be are there any best practices?

@lowl4tency: http://docs.datomic.com/backup.html#performance

robert-stuttaford: hah, why I didn't find it 😞

Thank you

perhaps you can increase the ddb write throughput

for the duration of the restore

http://docs.datomic.com/capacity.html#storage-size-and-write-throughput talks about a write of 1000 for imports

Hm, interesting

Will carefully learn it

Concurrency option and increasing ddb write throughput did restorin much quicker

Also, restoring is continious and begin from last interrupt. It's pretty cool

Does it make sense to give entities a UUID (if they don't already have a unique-based attribute) so that you don't have to resolve their :tempids after the transaction, and instead you can just return the UUID you gave to whoever needs it (which can then be used in a Lookup Ref)?

I've been seriously considering that technique for a few days, and the only drawback I can see is that it's an extra attribute and potentially superfluous data (considering the :db/id is essentially the same thing).

But there are two benefits for this: (1) you don't have to resolve the tempid, and (2) the UUID can be shared/consumed externally whereas the :db/id cannot.

@sdegutis: datomic best practices document seems to suggest the uuid approach though they don't specifically say use a uuid. the example they give of using a unique identity is a uuid generated with datomic's index friendly squuid function

@sdegutis: Yes, @raywillig is correct. That is a good approach b/c entity IDs are not guaranteed to be stable across i.e backup/restore, etc, so whenever possible you should supply a domain identifier or an externally unique identifier: http://docs.datomic.com/best-practices.html#unique-ids-for-external-keys

@marshall: Excellent.

In this case, there seems to be little to no use for Datomic users to use :db/id, right?

It seems like the only place it would ever be used is to ensure that a transaction creates a new entity (via {:db/id (d/tempid :db.part/user) ...}).

@raywillig: Thanks!