What does the following mean? java.lang.String cannot be cast to clojure.lang.IPersistentMap

@sova it means you're using a string where you should be using a {}

Oh. Hmm let's see.

(GET "/k/:tag" [ tag :as ring-req ] (let [tag-result (f9db/get-blurb-by-tag tag)] {:status 200 :headers {"Content-Type" "text/html"} :body tag-result})) quantum jumped back down to something that works.

I see. It's more of a Ring thing.

Logic needs to live before you send a ring response map back

with {:body "" :session "" :headers "" :etc "tec"}

lessons learned tonight: else must live subordinately inside an if.

😄

I think isComponent is not useful for collections of components, because to be able to use it I need to model the relation as n-m, while in most cases it should be 1-n To make my point concrete, I disagree with the example given in this URL: http://blog.datomic.com/2013/06/component-entities.html

{:db/id #db/id[:db.part/db]
 :db/ident :order/lineItems
 :db/isComponent true
 :db/valueType :db.type/ref
 :db/cardinality :db.cardinality/many
 :db.install/_attribute :db.part/db}

[{:db/ident :order.line/order
  :db/valueType :db.type/ref
  :db/cardinality :db.cardinality/one}
 {:db/ident :order.line/product
  :db/valueType :db.type/ref
  :db/cardinality :db.cardinality/one}
 {:db/ident :order.line/quantity
  :db/valueType :db.type/long
  :db/cardinality :db.cardinality/one}]

isComponent and cardinality are orthogonal concepts. Use is-component when you need an entity to have value-semantics instead of identity-semantics @joelsanchez

@favila that clears it up a little bit, thanks

Also in your n-m example, note the reverse ref from line item to its parent is card-one not many

This is true of all isComponent attributes when followed backwards

yes, but when the :order/lineItems attribute exists, any order can refer to any lineItem, even those that are not of its ownership

but I guess I shouldn't worry about that

The implicit invariant with isCompnent data (which datomic assumes but does not check) is that there is only ever one reference to its value

makes sense for Datomic to assume so, since it deletes isComponent values when the referrer is deleted

More specifically, (d/datoms db :vaet the-component-entity) will only ever produce one datom, whose attr is an isComponent attr

So the lineitems should be wholly owned by their order, but datomic isn’t going to check for you

Your application should ensure it

(Owner transfership is possible too without breaking the invariant)

thanks for the explanation, it goes in a similar way to refs then 🙂 (you're allowed to refer to any entity but if your app requires a certain constraint you should handle it or write a db/fn)

Yes. IsComponent is a strange annotation in that it’s on attrs but it really asserts something about entities

It’s the closest thing to entity schema that exists natively

previously I thought about it as a sort of "ON DELETE CASCADE" equivalent

so...will be changing my schema! 😂