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