@lmergen I'd have to see more thorough examples about what exactly you mean by "domain" and what facts you plan to store, but I would default to a single entity (e.g. pick its own namespace, neither accounting nor infrastructure) and make the distinction at the application level when querying. So, following your example, the schema might be customer/uuid, customer/name, customer/foobar, customer/accounting-id. Accounting queries would use pull to specify the attributes they want. Infrastructure queries would use pull or entity to get all customer attributes.

@daveliepmann i think you're right, that makes sense

i knew i was looking at this from the wrong perspective, but couldn't pinpoint what it was

i think the abstractions i'm trying to build are wrong, which is why it didn't really map that well to datomic entities

i should stick to a single entitiy in a single namespace, and make both domains query from that indeed

Does anyone know when Datomic Cloud is scheduled to come out?

hi, I'm having a little problem with enums:

{:db/ident :user.role/administrator}
{:db/ident :user.role/user}

{:db/ident :user/roles
 :db/valueType :db.type/ref
 :db/cardinality :db.cardinality/many}

(db/transact [{:schema/type :schema.type/user,
               :user/name "A test",
               :user/email "",
               :user/roles #{:user.role/user},
               :db/id 17592186045864}])
(db/touch-eid 17592186045864)
=>
{:schema/type :schema.type/user,
 :user/name "A test",
 :user/email "",
 :user/description "Test2",
 :user/roles #{:user.role/administrator :user.role/user}}