Deferred retrieval for data with one to many relationships?

[Peter Hunsberger]

I've got everything wired up and basically working for the Dynamic Schema question I had earlier but now want to check I'm not missing something before I end up implementing my own caching strategy.

It looks like most of the Deferred Fetcher implementation is aimed at more-or-less conventional Relational data structures?  As I mentioned previously, I'm using DataStax Enterprise Graph and in my use case you don't normally retrieve relationships with child items at the same time you retrieve a parent.  Instead you search for edges from the parent that connect to the children as a separate step.  If using Fetchers with Sangria I can do this in two steps, getting the edges and the Ids of the Vertexes they point to and then passing them into the deferred Fetcher.  However, there is little to no advantage to doing this; the query to get all the edges is about as expensive as the query to subsequently get the target vertexes and running the two queries separately is certainly more expensive then a single combined query. More-over, there really is going to be little re-use of retrieval of individual vertexes by Id.  So what I want is to retrieve an entire result set of vertexes based off of a single incoming key.  From what I can tell this means I'll have to use Deferred only and skip using Fetchers instead implementing my own caching strategy?

[Oleg Ilyenko]

This sounds like a good plan to me. Fetchers were designed with very specific use-cases in mind, namely to help get relational data based on either ID of entity or ID or an entity that relates to it and the relation type (classical one-to-one, one-to-many and many-to-many relations).

Deferred resolver was designed to cover much more broad set of use-cases. In fact, Fetchers are actually implemented as a `DeferredResolver`. So if you have some non-standard or non-trivial fetching logic, I would suggest to use `DeferredResolver` + `Defferred` values directly. in your case, it would be quite suitable since you need to fetch just 2 types or entities:  `Vertex` and `Edge` (`DeferredResolver` implementation becomes more complex if you have more entity types, this is why Fetch API was introduced in the first place).