fulcrologic / fulcro-rad-datomic Goto Github PK

Joining on an edge that points to an entity using only native IDs does not resolve anything because it is sending the non-native ID name to a pull, where :db/id is needed..

The generated resolvers in this plugin generate a pull request for everything an entity could have instead of what the resolver has been asked for. This generates unnecessary IO on the database.

When using native IDS:

• new instances in forms do not end up using tempids, and do not save properly

Currently requires db/id, but it is an easy fix to get that from the UUID

The recent change 658cb35#diff-fc8f7b85570d9a211b3e4904ab2555761bddf5eae5fb48070bea4c53db4c377dR14 introduces com.wsscode.pathom.core to com.fulcrologic.rad.database-adapters.datomic-common and the plugin will thus fail to load in a RAD project that only uses Pathom 2.

A possibly workaround is to have both v2 and 3 on the classpath, but then it is likely the new code won't work as intended under Pathom 3.

In Pathom 3, there is :com.wsscode.pathom3.connect.runner/root-query [{:product/all-products [...]}], which I guess is equivallent of P2's client-query . (P3 also has :com.wsscode.pathom3.interface.eql/source-request :pathom/ast with {:type :root, :children [..]} with the AST of that query, but to support both P2 and P3, it is likely best to use the raw 3 query) I realize now that root-query is something very different from parent-query (which is specific to the current resolver). I've asked for advice in #pathom.

The simple fix is to replace :as with :as-alias in the require, and do not support minimal-pull? for Pathom 3. I am trying to figure out whether we can do something better for P3... .

which makes the value nil

I'm working on RAD authorization for my project, and I've noticed that the built-in RAD Auth is depended upon by the Datomic/Cloud automatic ID resolver generators, namely here and here.

This is a bit unfortunate, because it "blesses" RAD's authorization implementation with no means to work around it.

I'm wondering if this is still necessary following the work done by @tylernisonoff in #10, which adds generic transform capability. It seems likely that RAD's redact routine could be moved out into a transform, and could then be opted into/out of at will by library users.

I'm willing to make this change, but I want to make sure I'm not missing something obvious.

Thanks for taking a look.