search

vapor-community / pagination

Simple Vapor 3 Pagination
MIT License
64 stars 15 forks source link

Support for `join`/`alsoDecode` #12

Open Cellane opened 6 years ago

Cellane commented 6 years ago

Motivation Behind Feature

At this moment, unless I’m mistaken, Pagination needs to operate on a QueryBuilder that produces Future<[Model]>. That makes it unable to paginate results that also fetch data from a different table, by using the Fluent’s join(_:to:)/alsoDecode(_:) methods, as these change the eventual output of QueryBuilder to Future<[(ModelA, ModelB)]>.

Feature Description

It would be awesome if we could paginate even these slightly more complicated queries. I get a feeling that the eventual implementation would have to also rely on an implementation of #11 that would allow us to specify how should the end result be joined for a valid JSON representation.

Alternatives or Workarounds

None considered or thought of.

anthonycastelli commented 6 years ago

I've not given this much thought as it's not crossed my mind, however, I do see how this would be a need for some people. I'll look into implementing something like this, but if you do have any ideas, feel free to submit PR

damirstuhec commented 6 years ago

I think this would be a very welcoming addition. Personally, I have an example of a /feed route that should return a heterogeneous array of feed items with different types.

If we had support for something like @Cellane proposes, then we don't have to do a weird dance of type erasure in order to support decoding/encoding of that heterogeneous array and instead rely on the multi-type pagination to return a result including a separate array for every type.

anthonycastelli commented 6 years ago

Just wanted to circle back to these issues and say I haven't forgotten about them. Just been swamped lately so haven't had a chance to work on anything regarding these packages. 🙂

gperdomor commented 5 years ago

Any progress here?