geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blake Bender <bben...@pivotal.io>
Subject Re: [DISCUSS] Streamline return value from RemoteQuery
Date Wed, 15 Aug 2018 18:46:33 GMT
+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 <jbarrett@pivotal.io> wrote:

> Oh wouldn’t it be nice if it was asynchronous... :(
>
> > On Aug 14, 2018, at 8:56 PM, David Kimura <dkimura@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 <jbarrett@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 <dsmith@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 <
> agingade@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 <dkimura@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 <
> >> eburghardt@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
> >>>>>>
> >>>>>
> >>>>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message