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 > >>>> > >>> > >> >
