hello, what Pathom 3 version are you using?

I'm using the transitive dependency from that version of pathom-datomic,

(looking it up now)

try using all the latest

Pathom just released, and bad83ee5a5973a259b2afad766fc043ab91e6b99 for pathom3-datomic

same error with:

com.wsscode/pathom3        {:git/url ""
                                         :sha "d52e431223c3dde193ab07a7bd4dda6c2a24edf7"}

             com.wsscode/pathom3-datomic {:git/url ""
                                          :sha     "bad83ee5a5973a259b2afad766fc043ab91e6b99"}

Pathom 3 has a maven version, you can use 2022.04.20-alpha

but still, maybe its a legit bug, let me look closer

Same issue.

@U087E7EJW can you try pathom3-datomic 9dfa5838b8ae9b5a7caa5d3a4d2eae5bdadc6373 please?

(just pushed a fix on it)

that fixed it!

thank you

thanks for reporting 🙏

Have you considered dropping the -alpha suffix? Every time someone asks if it is safe to migrate to v3 the answers are: "Everything from v2 is working in v3" "We use v3 in production for the last x month, without issue"

yeah man, from time to time I think about it, my lack of confidence at this stage is more around dynamic resolvers, there still some rough edges there, but maybe that can be addressed with more specific indications

what are people testing dynamic resolvers for right now? I'd like to help but can't think of a use case and I think I use pathom pretty extensively

but you could always mark it as stable with some features in alpha

dynamic resolvers are now used for GraphQL integration, but most important for me is to integrate Pathom with other Pathom instances, enabling a distributed processing architecture

yeah, it's a really cool idea but what problem do you see it solving today

typically those would be exposed as graphql APIs anyway right

one simple and interesting way I think to try it is to design the system to have 2 Pathom, one in the server, one in the client, this allows you to delegate some processing parts to the client

ah right, forgot I was meaning to use that to build a caching layer for fulcro

pushing further, a 3 pathom instances could go: Web <-> Web Worker <-> Server, this allows for choosing that specific portions should be computed at the web worker to dont freese the UI

a little worried about bundle size/initial js load time with that

and the most interesting for me is when dealing with micro-services, making each service provide its own graph, so you could plug in multiple graphs at once, while allow teams to develop them independently

why the worry on size / initial load? the webworker is an extra load that can go in parallel with the main page

I haven't thought about web workers actually, it is interesting. currently I am not using pathom in the client at all and I know pathom has a bit of cold overhead

Is it possible to shim the experimental features out of the main repo in a way that can be easily reintegrated once those experimental features are more stable? The core shouldn't have to appear unstable just because of some optional features still under observation. Reitit is a good example of a lib that does this subdivision thing well: https://github.com/metosin/reitit/tree/master/modules

not in this case @UANMXF34G, because the dynamic resolvers are a core part of the processing and have tight integration with the rest (I can't split the dynamic parts, its a facet of the process)

I would feel much more comfortable in upgrading my pathom2 app to pathom3 if it weren't alpha.

this looks like a missing setup of ident attributes, can you give an example of what this query would look like in GraphQL? this way we can figure how to make the ident attributes settings

ah, sorry, I confused graphql with datomic, there are not ident attributes on datomic, can you make a repro caso of what you are experiencing?

^ @wilkerlucio this is our repro using Datomic dev-local (client-api)

thanks for the repro, hope to look at it soon, just been a busy week :)

thank you!

hello, I just had a look in the repro, but I notice the changed example is starting from an empty database, the original tests connect to the mbrainz database (per this line: https://github.com/secos/pathom3-datomic/commit/0c4dafb5e47046b9450075b1e73357ced4cecbec#diff-682efd186f370fa01384ae9ce43d3091d9cf2c63d71d9e2ddb25b020c7155e78L15), so without connecting to the mbrainz its expected that all the tests fail, because they assume we will have the mbrainz schema/data there for testing

My apologies for missing that! I’ll get it sorted.

awesome, thanks, gonna check it out

@U03B7KALC3Y sorry the long time on this one, I merged this commit to main and it should fix the ident lookup: https://github.com/wilkerlucio/pathom3-datomic/pull/3/commits/8104c727f79f1ad52d2a9b8aaeac350f5e7c8bd0

this made your test case pass, please let me know if you still have issues

Thank you @wilkerlucio. Will take a look!

That worked @wilkerlucio - thank you so much!