You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Ernest Burghardt <eb...@pivotal.io> on 2018/08/13 23:06:34 UTC
[DISCUSS] Streamline return value from RemoteQuery
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
Re: [DISCUSS] Streamline return value from RemoteQuery
Posted by David Kimura <dk...@pivotal.io>.
On Wed, Aug 15, 2018 at 5:24 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> Oh wouldn’t it be nice if it was asynchronous... :(
"Hold my beer" :P
Re: [DISCUSS] Streamline return value from RemoteQuery
Posted by Blake Bender <bb...@pivotal.io>.
+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 <jb...@pivotal.io> wrote:
> Oh wouldn’t it be nice if it was asynchronous... :(
>
> > On Aug 14, 2018, at 8:56 PM, David Kimura <dk...@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 <jb...@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 <ds...@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 <dk...@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
> >>>>>>
> >>>>>
> >>>>
> >>
>
Re: [DISCUSS] Streamline return value from RemoteQuery
Posted by Jacob Barrett <jb...@pivotal.io>.
Oh wouldn’t it be nice if it was asynchronous... :(
> On Aug 14, 2018, at 8:56 PM, David Kimura <dk...@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 <jb...@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 <ds...@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 <dk...@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
>>>>>>
>>>>>
>>>>
>>
Re: [DISCUSS] Streamline return value from RemoteQuery
Posted by David Kimura <dk...@pivotal.io>.
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 <jb...@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 <ds...@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 <dk...@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
> >>>>
> >>>
> >>
>
Re: [DISCUSS] Streamline return value from RemoteQuery
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <ds...@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 <ag...@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 <dk...@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
>>>>
>>>
>>
Re: [DISCUSS] Streamline return value from RemoteQuery
Posted by Dan Smith <ds...@pivotal.io>.
+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 <ag...@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 <dk...@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
> > >
> >
>
Re: [DISCUSS] Streamline return value from RemoteQuery
Posted by Anilkumar Gingade <ag...@pivotal.io>.
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 <dk...@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 <eb...@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
> >
>
Re: [DISCUSS] Streamline return value from RemoteQuery
Posted by David Kimura <dk...@pivotal.io>.
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 <eb...@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
>