Fork me on GitHub

is there a way to filter out stuff that goes to PathomViz, like Datomic conns and dbs? turns out they OOM when transit tries to emit them 😆 for now i'm just treating them as globals, but it'd be nice to have a conn and a db resolver instead


hello Robert, currently there is no option to do that for a specific location, but I feel your pain, some payloads are just huge (and other non encodable) and that cripples the tooling


one option you have today is to ask only for the shape of the outputs, instead of the data, setting the flag ::pcr/omit-run-stats-resolver-io? true, this will make the output contains the shapes of the data, but not the data


I'm wondering what a good way would be to fix this, I have two ideas in mind


1. make it per-resolver, and mark that a specific resolver shouldn't log its outputs


2. make it per-attribute, so the user can say some specific attributes should not log their values (in both inputs and outputs)


I'm more inclined to do solution 2, seems more general and more reusable


yeah, 2 would be great


or if we could run the payload through a function just before it sends, we could alter or control it as we like


i'd simply #(dissoc % :datomic/conn :db) but i could imagine running transformations to summarise/aggregate purely for ease of Viz


Viz is fantastic by the way


@U066U8JQJ would you be open to hanging out for 30-45 mins some time to map out the work here, so we can figure out how i can help? 🙂

👍 1

@robert-stuttaford I wonder if creating a resolver for the datomic db is not a security risk.


it is, if you expose pathom directly to the network, yeah!


I thought that this is how it should be used 😅 Thanks!


there is an example on the plugins page on how to prevent certain attributes to getting out:


@robert-stuttaford, yes, you are using pathom2 or 3? high level how: You will need to reimplement/overwrite this resolver, that returns the index


thanks @U2J4FRT2T! pathom3. i'll track it down


I don't recommend trying this on Pathom 2 though, the implementation there is old, naive and its not getting upgraded


3 all the way here 🙂

🙏 1

am i nuts, or could i set up multiple indices and compose them, i.e. resolvers using smart-maps from layers lower down?


I think so, can you make an example to be more specific on what you have in mind?


smart-map (aka resolver index) one: general info about the session/user/environment smart-map two: specific info for a specific sub-system, e.g. access control stuff for a CMS Two's resolvers have access to One's smart-map


that should work right, there's nothing preventing this sort of composition


I mean a code example 😅, I'm trying to understand exactly how to mean to integrate them, to rationalize about the implications


smart maps as values I don't think will work as expected, because there is a lot of merging going on and smart maps merge won't be mergning their indexes


also, in general, smart maps are more costly than running EQL queries, and on the client-side they don't support async process


so, in general EQL is the preferred interface, the use case I see for smart maps are more related to using Pathom to integrate with things that require some kind of map interface, but if you don't have such restriction, EQL should be preferred


ok great, looks like my question produced value 😄