@wilkerlucio is it a "undefined" behavior?
If there is 2 resolvers to resolve :a
, one is "global", the other need a input :i
The pc/reader3
will prefer "the first one", where "the first one" is "the first inserted in the index" (aka the register order matters, with I think is bad)
Sample case
(let [register [(pc/resolver
`user-name-by-id
{::pc/input #{:user/id}
::pc/output [:user/name]}
(fn [_ {:user/keys [id]}]
{:user/name (str "user-" id)}))
(pc/resolver
`current-user-name
{::pc/output [:user/name]}
(fn [_ _]
{:user/name "current"}))]
parser-1 (p/parser {::p/plugins [(pc/connect-plugin {::pc/register register})]})
parser-2 (p/parser {::p/plugins [(pc/connect-plugin {::pc/register (reverse register)})]})
env {::p/reader [p/map-reader
pc/reader3
pc/open-ident-reader
p/env-placeholder-reader]
::p/placeholder-prefixes #{">"}}]
{:parser-1 (get (parser-1 env [{[:user/id 1] [:user/name]}])
[:user/id 1])
:parser-2 (get (parser-2 env [{[:user/id 1] [:user/name]}])
[:user/id 1])})
=> {:parser-1 {:user/name "user-1"}, :parser-2 {:user/name "current"}}
currently reader3 doesn't have a real algorithm to pick a path, the current impl will use first
, that's a current incomplete part of it
Is it tracked? Should I open something to track it? I'm not sure if how it should behave actually
I've never used Pathom before but it seems like a natural fit for my usecases to access a bunch of data in ElasticSearch. One of usecases is to serve autocomplete in the UI. I don't see any reason NOT to use Pathom for this usecase (except, possibly, performance). Am I wrong?
@markaddleman in the end pathom is just a glue to compose information across your system, I have used pathom with ES before, don't see any reason not to 🙂
Thanks for confirming! I'm looking forward to this little project