Oh wouldn’t it be nice if it was asynchronous... :(
> On Aug 14, 2018, at 8:56 PM, David Kimura <dkim...@pivotal.io> 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 interface. > > Thanks, > David > >> On Tue, Aug 14, 2018 at 12:57 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: >> >> 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 similar in behavior. >> >> -Jake >> >> >>> On Aug 14, 2018, at 11:01 AM, Dan Smith <dsm...@pivotal.io> wrote: >>> >>> +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 query::executeXXX method for each type. >>> But I think just returning StructSet seems reasonable. >>> >>> The Java API for query is even worse. I think the Java API actually >> returns >>> an Object, which the user has to cast into one of three things - an >>> individual value, SelectResult of values, or a SelectResults of structs. >> We >>> should fix that too! >>> >>> -Dan >>> >>> On Tue, Aug 14, 2018 at 10:47 AM, Anilkumar Gingade <aging...@pivotal.io >>> >>> wrote: >>> >>>> 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 <dkim...@pivotal.io> >> wrote: >>>>> >>>>> 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 < >> eburgha...@pivotal.io >>>>> >>>>> wrote: >>>>> >>>>>> Currently, geode-native's query::execute returns a >>>>>> shared_ptr<SelectResults> 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 removal of ResultSet which will streamline the API and >>>>>> associated code... >>>>>> >>>>>> This duality is unnecessary and should be removed. >>>>>> I am proposing that the results only return StructSet >>>>>> >>>>>> Best, >>>>>> EB >>>>>> >>>>> >>>> >>
