I believe the schema design in Datomic is pretty similar to Postgres. Design the users, orders, stocks tables on paper. These will be entities connected with foreign keys. Then transfer it to Datomic. The only difference is the foreign keys become refs.

(def db-schema
  [{:db/ident       :product/id
    :db/valueType   :db.type/long
    :db/unique      :db.unique/identity
    :db/cardinality :db.cardinality/one}
   {:db/ident       :product/label
    :db/valueType   :db.type/string
    :db/unique      :db.unique/identity
    :db/cardinality :db.cardinality/one}
   {:db/ident       :product/type
    :db/valueType   :db.type/string
    :db/cardinality :db.cardinality/one}
   {:db/ident       :product/model-no
    :db/valueType   :db.type/string
    :db/cardinality :db.cardinality/one}])
(d/transact conn {:tx-data db-schema})

(def stock-schema
  [{:db/ident       :stock/product
    :db/valueType   :db.type/ref
    :db/cardinality :db.cardinality/one}
   {:db/ident       :stock/amount
    :db/valueType   :db.type/long
    :db/cardinality :db.cardinality/one}])
(d/transact conn {:tx-data stock-schema})

(def order-schema
  [{:db/ident       :order/product
    :db/valueType   :db.type/ref
    :db/cardinality :db.cardinality/one}
   {:db/ident       :order/user
    :db/valueType   :db.type/ref
    :db/cardinality :db.cardinality/one}
   {:db/ident       :order/size
    :db/valueType   :db.type/long
    :db/cardinality :db.cardinality/one}])
(d/transact conn {:tx-data order-schema})

(def user-schema
  [{:db/ident       :user/id
    :db/valueType   :db.type/long
    :db/cardinality :db.cardinality/one}
   {:db/ident       :user/name
    :db/valueType   :db.type/string
    :db/cardinality :db.cardinality/one}
   {:db/ident       :user/password
    :db/valueType   :db.type/string
    :db/cardinality :db.cardinality/one}])
(d/transact conn {:tx-data user-schema})

(def product-data
  [{:product/id       100
    :product/label    "lacoste"
    :product/type     "urban clothing"
    :product/model-no "polo shirt"}
   {:product/id       101
    :product/label    "canada goose"
    :product/type     "jackets"
    :product/model-no "caban"}
   {:product/id       102
    :product/label    "mammut"
    :product/type     "boots"
    :product/model-no "hiking boots"}
   {:product/id       103
    :product/label    "husky"
    :product/type     "sleeping bags"
    :product/model-no "arnapurna"}])
(d/transact conn {:tx-data product-data})
(def db (d/db conn))                                        ;;refresh database

(def stock-data
  [{:stock/product (get-entity-id-by-label "lacoste")
    :stock/amount  10}
   {:stock/product (get-entity-id-by-label "canada goose")
    :stock/amount  8}
   {:stock/product (get-entity-id-by-label "mammut")
    :stock/amount  6}
   {:stock/product (get-entity-id-by-label "husky")
    :stock/amount  4}])
(d/transact conn {:tx-data stock-data})

Yes, As you can say I need to learn about refs. I tried to build an example db with relations. But I am not sure about my refs, reletions are built correctly. I saw some examples that generally puts refs into vectors which is a different attempt then what I tried. Some kind of things. 🙂

Just a note: your product has two unique fields: product/id and product/label. Du you really need both?

I think that's a mistake.

I guess I have to change it, isn't it?

Usually a good has SKU or similar unique string. Once you're created an entity in Datomic, it obtains a unique id so there is no need to pass it explicitly

so in your case, a unique string field product/sku would be fine. But it depends on your data, after all. If you import some legacy data from Postgres, you might need to track the old Postgres ID for rare cases.

Is this unique field help me to track that issues?

well, I don't know. I just noticed that your product has two unique fields, and one of them is an integer which is a bit redundant.

Yes, thanks for sharing with me. That was a mistake I just fixed in my repo. 🙂

https://max-datom.com/ is fun to work through

Thanks 🙂

@U9E8C7QRJ hello thats nice and fun. Where can I find solutions do you know?

Those docs are for cloud using the client api (datomic.client.api/transact). You are using on-prem peer api (datomic.api/transact), whose parameters are a different shape.

> Execution error (ClassCastException) at datomic.api/transact (api.clj:105).

Thanks, I didn't notice 😅

(Using the same “d/” namespace alias for the client api in official documentation was I think a really big mistake. I personally always use dc/_ to distinguish)

@U09R86PA4 Thanks for pointing out that subtle confusion with d/. We're working on some docs updates and have added that to the list of things to evaluate.

in implicit entity-id resolution contexts (e.g. d/entid, keyword lookup on an entity map, pull expressions, the attribute slot of a datalog clause), no-longer-asserted idents still resolve

this is by design, so you don’t have to change code and data in lockstep when renaming attributes

i.e. both :file/path and :deprecated/file.path will resolve to the same attribute

but [?attr :db/ident :file/path] in a datomic query will not

@U015VUATAVC For now it is still only available through the Cognitect repository. If you could share why you find this problematic, that may inform choices we make when improving how to get dev-local.

The long story short is when circulating demos around people need to register and then modify their maven repository settings to put the token @UEFE6JWG4

Assuming there is no license problems since now the platform is free, having it just on Mavens would make my life easier

Right, makes sense. We hope to have something that will make this much easier for you after we've worked on some other follow up work (e.g. Cloud)

Thank you!

Yes, many teams mention the maven setup as an annoyance. Here on the DevOps side it even made us loose some days with a hard to understand issue happening only in the context of Docker-based github actions.

A blog post would be great when dev-local distribution changes. This is something I'm very keen on and I'm sure others are as well.