This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-27
Channels
- # announcements (4)
- # asami (6)
- # aws-lambda (1)
- # babashka (38)
- # babashka-sci-dev (20)
- # beginners (87)
- # calva (67)
- # cider (19)
- # clerk (13)
- # clojure (102)
- # clojure-europe (52)
- # clojure-filipino (1)
- # clojure-hungary (4)
- # clojure-nl (1)
- # clojure-norway (6)
- # clojure-sweden (3)
- # clojure-uk (1)
- # cursive (13)
- # data-science (7)
- # datomic (8)
- # deps-new (1)
- # emacs (3)
- # fulcro (16)
- # graphql (3)
- # humbleui (3)
- # kaocha (3)
- # leiningen (3)
- # malli (3)
- # off-topic (14)
- # pathom (34)
- # polylith (4)
- # rdf (12)
- # reitit (3)
- # releases (1)
- # remote-jobs (7)
- # rum (2)
- # sci (22)
- # shadow-cljs (115)
- # tools-deps (26)
- # tree-sitter (29)
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/all-products
[:product/id
{: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. 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
I just realized it worked before because I did not access the report which loads the denormalized data.
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…
@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.
For performance I think you might want no normalization when thre are many many rows….it’s desirable
Now when you say it is obvious…
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
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.
I have this in my env
:com.wsscode.pathom3.format.eql/map-select-include #{:tempids}
Not sure what it does
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.