Clojurians Log v2

Thanks. I may have oversimplified the real use case. In real life, dimensions-attributes pulls data from a elastic search which may have zero, one or many documents that match a query

I feel like there ought to be a solution on the field-list resolver by using pco/? but I can't find a magic combination to get the results that I want

@markaddleman just did tried here

I believe this has the change you want:

(pco/defresolver field-list [input]
  {::pco/input  [{:attributes/dimensions [(pco/? :attribute/id)]}]
   ::pco/output [{:pivot-table/fields [:pivot-table.fields/list
                                       :pivot-table.fields/count]}]}
  {:pivot-table/fields {:pivot-table.fields/count (count (:attributes/dimensions input))
                        :pivot-table.fields/list  (mapv (comp (fn [raw] {:pivot-table.field/id raw}) :attribute/id) (:attributes/dimensions input))}})

try with this resolver modified, and let me know if that's expected result now

Thx. I'll give it a try right now

ops. I just noticed this broken the first example ("not empty")

Yeah

I thought I had tried that 🙂

It's as if pco/? is causing Pathom to give up too early

Is it expected that we’d need to make it optional? I would think that {:attributes/dimensions []} would still fulfill:

[{:attributes/dimensions [:attribute/id]}]

its different specifications

I guess in his case, the list is mandatory, but the some parts of the list content are optional

Pathom will only consider a sub-query valid if the required fields there are fulfilled

in that sense, the Pathom behavior is correct in the initial example

because the "empty" case can't fulfill the item detail

altough, this seems a special case up to discussion, over what to do when the collection is empty

in this case, should the input be considered valid, or invalid?

@markaddleman changing from required to optional and stop working is for sure a bug, going to work on that in a bit

Thanks! This is one of the last bits for me to switch completely to Pathom3.

(to be clear, this is new functionality - I haven't tried this in Pathom2)

no nested inputs in Pathom 2, you are living the edge here 🙂

lol

I have many comments in our pathom2 code about where we will benefit from nested inputs 🙂

nice, and Im really asking your opinion here

in case of empty collections, what you think would be the most sane default?

consider the input valid, or invalid?

(currently is invalid)

and to make a case for valid, the @markaddleman code would work without need for optionality on the fields, if valid was the answer

In my opinion an empty collection is valid b/c it does fulfill the contract. For every item in the collection (zero items) they have an :attribute/id

yeah, I'm tending to that side too

most nested inputs are mostly about aggregation, and aggregation on empty collections most commonly expected to be valid

From my standpoint, it took a little bit of staring to understand why the empty collection was not triggering the id resolver.

It would have been more natural if it had

yeah, ok, expect that to change, soon 🙂

awesome! what happens if some of the elements fulfill the nested input requirement but others don’t? I don’t have a real life example, but just curious

in that case its considered a match, but some items may have missing requirements

wonder if would be sane to filter it out

From my standpoint, it would be sane to filter those out. I conceptualize pathom's behavior as a database JOIN operation. If some attributes don't exist on one side of the join, they aren't in the result set

ya, i also think filtering out those missing the required key is sane behavior. if you didn’t want them filtered out i’d imagine you could make the nested key an optional key instead of required

I agree with you guys

valid empty inputs just landed on master! @markaddleman you may wanna give a try if you still up 🙂

right after dinner. Thanks!

Works perfectly!

Thank you!

you'r welcome 🙂

so now in cases of collections and parts of the items are missing the requirement, these items are filtered out

Yep. I just updated my code to remove pco/? . Makes it easier to understand, I think

yeah, and is the correct expression in your case

that’s awesome! thanks for the quick updates! excited to play around with the changes

🎉 New docs for how nested input filtering behaves: https://pathom3.wsscode.com/docs/resolvers#nested-inputs-filtering

🎉 New built-in plugin, now you can easely make mutation params resolve like resolver inputs! https://pathom3.wsscode.com/docs/built-in-plugins/#resolve-mutations-params

@cjmurphy if I remember right you were looking for this one a long time ago

nice! would be great to be able to apply this plugin non-globally to a single mutation in opts map, kinda like augmentation via pco/transform

@wilkerlucio Looks like submitting invalid queries can cause the UI to lock up on Pathom Viz

i.e. [{[:curriculum/uuid <snip>]}]

Which is missing the value to the map which should def. error

but the UI shouldn’t require a hard reload IMO

not this plugin directly, but you can make a transform for that

agreed, can you please open an issue at the pathom viz repo?

https://github.com/wilkerlucio/pathom-viz/issues/25

Side note, thanks for the amazing tool!

Can you specify params for specific inputs in your resolver? I’d like to have a resolver depend on an input with a specific parameter always applied. My current workaround is to create another resolver that always applies the param but was curious if I could do it along with the input.

no support for that

👍 thanks! i think i can accomplish what i’m trying to do when i switch to pathom3 by using nested inputs along with the filtering of missing keys

Related to yesterday's discussion - Now my field-list resolver takes two separate inputs. Both of which can be optional. The first query returns the result I expect. The second query should only invoke the dimension-attributes, dimension->attr-id resolvers and field-list resolvers but returns an empty result instead.

I think this is b/c with your second option you only provide :k1 so it seems like it’s impossible to get to :attributes/profiles which is not marked as optional in your field-list resolver

The sub-key is optional but it still needs a key of :attributes/profiles which pathom cannot get to with your second query since the only resolver that provides :attributes/profiles requires both :k1 and :k2 .

I bet if you updated the field-list input to be this it would work: (pco/? {:attributes/profiles [(pco/? :attribute/id)]})

or another option would be to mark :k2 as optional in your profile-attributes resolver

@markaddleman before I check it closer, did you upgraded Pathom today? because today I made a fix related to nested optional inputs

one other tip, you can use the arity 3 on process to make your execution result simpler (by removing the nesting under the placeholder):

(p.eql/process env
  {:k1 "not empty"}
  [{:pivot-table/fields
    [:pivot-table.fields/count
     :pivot-table.fields/list]}])

Yes, I'm using head

doh - Thanks for the arity 3 pointer. That simplifies things.

@dehli

(pco/? {:attributes/profiles [:attribute/id]})

@markaddleman wrong place, this is how you do it:

{(pco/? :attributes/profiles) [:attribute/id]}

I just tested, that got some results with your code

and the things that @dehli said were accurate

its the k2 missing dep that's making pathom give up on that

Im quite happy how you are pushing the boundaries, will be even happier if all works as expected XD

No worries. I sort of expected this when I decided to go P3.

And, to be sure, P3 is proving to be a win for me overall

Yeah, if I mark :k2 as optional in the profile->attri-id resolver, field-list produces results but it's the wrong results. There should not be profile in the result from field-list because :k2 isn't in the input

I'm gonna check that, in the meantime, what about optional on :attribute/profiles?

That works but... (i think I tried earlier and had a problem)

about the optional :k2, I believe its behaving correctly, you made that optional, so it runs the resolver and retuns the list

This yields the correct result:

::pco/input  [{:attributes/dimensions [:attribute/id]}
               {(pco/? :attributes/profiles) [:attribute/id]}]

However, this

::pco/input  [{(pco/? :attributes/dimensions) [:attribute/id]}
               {(pco/? :attributes/profiles) [:attribute/id]}]

And this ^^ is closer to my real use case

interesting, I have a guess on why 👀

ok, that seems a simple spec oversight, the result is correct?

spec fixed on master

I haven't tried turning off guardrails. I'll update to newest master and retest in a few minutes

Under latest master,

::pco/input  [{(pco/? :attributes/dimensions) [:attribute/id]}
               {(pco/? :attributes/profiles) [:attribute/id]}]

I usually use guardrails with throw false

so even when it complains, things still go on