+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<std::string, std::shared_ptr<Struct> >, and client developers really wouldn't lose anything of value in the process.
On Wed, Aug 15, 2018 at 5:25 AM Jacob Barrett <jbarr...@pivotal.io> wrote: > 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 > >>>>>> > >>>>> > >>>> > >> >
