Fork me on GitHub
Jakub Holý (HolyJak)19:01:57

Question about RAD and ro/column-EQL - it leads to changing an attribute in the client DB from an ident to a map, thus breaking the relationship / normalization. I have a ProductReport with columns including [... r.product/customer] where this attribute is defined as:

(defattr customer :product/customer :ref
  {ao/target :customer/id
   ro/column-EQL {:product/customer [:customer/name]} ; as in the column-EQL docstring
   ro/column-formatter (fn [_report value _ _] (:customer/name value)),,,})
Now the problem with this is that RAD sends the following query:
    {:product/customer [:customer/name]}
and as a result gets back {:product/id ..., :product/customer {:customer/name "Fantomas"}} - i.e. the request and response lack :customer/id and the customer won’t be normalized. That is a problem. I am not sure what is the solution. Including :customer/id in the EQL is not sufficient for the data to be normalized, which is kind of logical b/c I do not use (get-query ...) in the EQL so Fulcro lacks the meta data to know how to normalize it. But I believe this worked fine for me before.I upgraded dependencies and switched from Pathom 2 to 3. @wilkerlucio WDYT, who should be responsible for referenced entities to always have their <entity>/id in EQL responses? Fulcro or Pathom? Thanks!


given normalization is a fulcro concern, I think its up to Fulcro to make it is being requested. I also not sure how it could work without that before, pathom never added any key by itself

👍 2
Jakub Holý (HolyJak)20:01:06

I just realized it worked before because I did not access the report which loads the denormalized data.

Jakub Holý (HolyJak)20:01:45

I guess that defsc-report could be smarter when it has an attribute with column-EQL and do something like this: 1. If it is :ref then add the ao/target value to the EQL, if not there already (and it is a join) 2. if ref & join then add to it metadata that tell Fulcro how to normalize it. Normally the metadata has :component so either the defsc-report would need to construct a component for each such column-EQL (likely w/ nc/rc) or we’d need to add support for something else… WDYT, @U0CKQ19AQ? I’d be happy to contribute…

Jakub Holý (HolyJak)07:02:48

@U0CKQ19AQ sorry to bother but I need your advice on column-EQL & normalization 🙏 ☝️


no no….if you want normalization, use a component and get-query in column-EQL. it already works.


no automation desired or acceptable for that IMO…the facilities already exist


everything in Fulcro is CLJC


For performance I think you might want no normalization when thre are many many rows….it’s desirable

Jakub Holý (HolyJak)22:02:54

Now when you say it is obvious…

Jakub Holý (HolyJak)19:01:42

Question two: any tips how to avoid (w/ Pathom 3) this error log > _rad.pathom3:- 31 - EQL query for :tempids cannot be resolved. ? I believe frontend adds this so that, if returned, they will not be dropped from the data but of course Pathom has no idea what to do with it… FYI the EQL was [{(com.fulcrologic.rad.form/delete-entity {:order/id 123}) [:tempids *]}]


I guess you can use a constantly resolver to return a blank map there? or maybe nil, not sure whats fit better in this case

👍 2
Jakub Holý (HolyJak)20:01:54

Thank you! I will try that. Though ideally I think we would solve it on fulcro side, so that users do not need to be bothered with this. Perhaps have a whitelist of things to not remove from the returned data even if they are not asked for in the query.

Eric Dvorsak21:01:49

I have this in my env              :com.wsscode.pathom3.format.eql/map-select-include #{:tempids} Not sure what it does

Jakub Holý (HolyJak)11:01:49

I guess it adds :tempids to the incoming EQL, probably so that - if returned by a mutation - it is not filtered out even if not requested explicitly.