Antoine Pelisse
Antoine Pelisse
Agreed, but I think it's wrong that fields are both required and defaulted, we can't fix that in the api now, but we should strongly recommend not having these.
I would maybe consider this a feature more than a bug, but it's debatable :-)
I suspect there are two things that are going to make the non-caching behavior happen: 1. If we have to sort the results, we need to receive them all fist....
> I'm not too sure on this one but Infos() is already called to fetch the requests before we reach the multi-gvk stuff. Yeah, keep digging there, you might find...
Sure, can you dig deeper and make sure that they are not eventually sorted anyway on a simple get? If there is no sorting involved, that would probably make things...
Agree about the post/pre processing in `apply`, but I'm hoping this is unrelated because it's `get`. I agree that sorting will make it difficult, but in that case, would be...
First, prune is not really supported (@seans) so I don't know how much we'll want to support this. Also, what do you mean you would expect "an array of items"?
Yep, that's how you ask things to the server. Somewhere we must build a list but we don't with pruning?
That's really awesome! I'm curious how/if you handle fields that are owned by multiple managers? I'm also a little concerned about the output width, so I'm curious if you thought...
Looks great!