Is there a built in way to get the created-at and updated-at values for an entity?

Or should I store those as attributes on an entity?

@currentoor: you can get created-at and updated-at information using Datomic’s time capabilities, answer here - http://stackoverflow.com/a/24655980 - is relevant.

awesome! I should have searched around more.

I am curious how many are leveraging Datomic REST interface vs. a server side handler.

When I run the first function (with transactions expressed as a list with :db/add) it works, but it doesn't with map, am I doing something wrong ? according to the doc I should be able to do {:db/id entity-id attribute value}

@yenda: if [:param/name parent] is meant to be a lookup ref, the map form key corresponding to it should be :db/id not :db/ident.

yeah sorry I have that it says :db.error/entity-missing-db-id Missing :db/id"

@yenda: if :param/attributes is cardinality many, you need to put the vector specifying the lookup ref in another vector, e.g. [[:param/name child]], and in that case it would be interpreting child as the second item in a list of refs, which could return that error.

@bkamphaus: thank you that was it !

Does an attribute of :db.type/string and :db.cardinality/many preserve order of the strings?

@sdegutis: nope, just sets, so order is not guaranteed. However, if they’re all individually transacted and you want the order in which they were transacted, that’s recoverable from the transaction entity for each transaction (in query, etc.). If you mean within the collection of values supplied to the transaction, there’s neither intrinsic nor recoverable order.

Ahh good point!

I was afraid I'd have to create a new many-ref that points to entities that have a string and timestamp.

But in this case, the transaction order is what matters. So it's easier, thanks to Datomic's history stuff. Phew!

Thanks @bkamphaus

right, provided it’s the time it went into Datomic or the time you supplied by setting the transaction instant, rather than some other domain time that’s of interest.

for the case of an ordered list of things I couldn't find a better solution than having a position attribute

@bkamphaus: Interestingly, :db/noHistory seems to have no effect on this, as I'm still able to add strings to a cardinality-many string attribute on a single entity, and query their transaction date along with the strings.

@sdegutis: noHistory is essentially an optimization hint and eventual, history is not preserved in the indexing process (as it usually is) and falls away. It doesn’t have the same guarantees as e.g. excise.

but the most recent attribute’s tx will always be there.

@bkamphaus: So you're saying it's guaranteed that something like this will work on a no-history attribte? (d/q '[:find ?when ?what :where [_ :some/thing ?what ?tx] [?tx :db/txInstant ?when]] db)

anything that is part of the present db is a datom and has a txid, so yes. It’s just things that have been retracted or previously asserted that will not be kept.

Excellent. Thanks!