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