On Wed, Aug 15, 2018 at 5:24 AM, Jacob Barrett wrote:
> Oh wouldn’t it be nice if it was asynchronous... :(
"Hold my beer" :P
+1 for always returning StructSet. Just this change would have pretty
minimal impact. We took a slightly more in-depth look at the code, and it
doesn't look like there's anything preventing us from converting most of
this stuff to standard library code. StructSet could be replaced with
std::map
Oh wouldn’t it be nice if it was asynchronous... :(
> On Aug 14, 2018, at 8:56 PM, David Kimura wrote:
>
> If this is a non-blocking function (and maybe even if it isn't), then it
> might be worth considering a future/promise contract. Perhaps something
> like folly which provides a very rich
If this is a non-blocking function (and maybe even if it isn't), then it
might be worth considering a future/promise contract. Perhaps something
like folly which provides a very rich interface.
Thanks,
David
On Tue, Aug 14, 2018 at 12:57 PM, Jacob Barrett wrote:
> If we are going to change it
If we are going to change it I wonder if we can’t do better or look for some
other standard to adopt.
For the C++ side could we adopt something that is maybe std::tuple or
std::vector based? Tuple probably doesn’t work because it’s fixed at compile
time but std::vector and StructSet are very s
+1 for just having StructSet.
Return types should always be strongly typed, the user shouldn't have to
introspect or guess based on their query what the return type actually will
be at runtime.
If we think there is value in having separate ResultSet and StructSet
results, we could have a separate
In Java, they are separated so that the results can be managed effectively.
For example StructSet has its own implementation to manage the query
results that are structs (more than one projection attributes).
-Anil
On Tue, Aug 14, 2018 at 8:28 AM David Kimura wrote:
> I have a couple question
I have a couple questions:
Do you have an idea or theories of what was the original intent behind
separating ResultSet and StructSet?
Is execute a blocking or non-blocking call and does the interface have any
guarantee of that?
Thanks,
David
On Mon, Aug 13, 2018 at 4:06 PM, Ernest Burghardt
wr
Currently, geode-native's query::execute returns a
shared_ptr and
that pointer can be either ResultSet or StructSet.
RemoteQuery::execute contains logical code to determine with QueryResults
are greater than 0... We should look at removing this logic and only
returning StructSets
This allows remo
