Strategies for getting only limited fields when an element may not exist

[AndrewLipscomb]

I'm following the strategies in https://github.com/microsoft/cppgraphqlgen/issues/182 for getting values as a batch vs getting everything and selecting just what the client wanted.

I'm now up against this sort of scenario

• I have an object that may or may not exist - the only way to check is to go to the DB
• I have a subset of fields I would like to get for that object, should it exist
• The "return-placeholder-then-collect-and-resolve-futures" method requires that you return something for the type represented by this batching level - but that then implies that the something is resolvable in the database (which in this case, it may not)

Is there any way to solve this without having to first figure out whether to return a placeholder or not by contacting the database? I would expect that beginSelectionSet would then need to have some way to be called before the placeholder is actually returned into the resolver functions - which I think isn't how it works.

But I might be missing some strategies here :)

If it helps to illustrate the "why" here - we are trying to present an interface for a fairly deep and somewhat recursive hierarchy of large geospatial data objects - so touching the database at all given their size is a non-trivial cost. All these elements are individually ID'd - but unfortunately the backend doesn't have a cheap exists(ID) style function

[wravery]

Sorry for the delay, I've been very busy over the last month. Maybe you've already come up with a solution, but the approach I'd try would be to create a proxy for the object which knows that it may not exist, and defer checking the DB to see if it exists until you have collected the fields you'll need on the proxy. In other words, the something you return for the type is agnostic about whether the DB object backing it exists until you have collected the fields. It's a "return-placeholder-then-collect-futures-then-check-existence-and-resolve-futures" approach.

[AndrewLipscomb]

the approach I'd try would be to create a proxy for the object which knows that it may not exist, and defer checking the DB to see if it exists until you have collected the fields you'll need on the proxy

The problem here is this though for a fake Parent and Child class; if I want to see a call for Child::beginSelectionSet I have to return something != nullptr for Parent::getChild().

I can't see a way around the seeming relationship between Parent::getChild returning != nullptr if you want to do any further iteration on the query tree, and Parent::getChild returning != nullptr meaning that the object underneath definitely exists.

ie: basically I can't see how to get "until you have collected the fields you'll need on the proxy" to actually be callable unless "checking the DB to see if it exists" is done first - as the class that has ChildProxy::beginSelectionSet is also expected to be able return ChildProxy::getMandatoryScalarField correctly

I'll keep having a play and seeing if I can see what you are trying to get at