You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Michael Carey <mj...@ics.uci.edu> on 2017/09/07 18:44:03 UTC
Time to deprecate AQL?
As AsterixDB evolves, and additional features are added - e.g., DISTINCT
aggregate support, or properly implemented query-bodied functions,
supporting two query languages is hugely expensive: Updating two
grammars, parsers, rules, tests, ... IMO it is time to let go of AQL as
an externally supported interface to AsterixDB and only have SQL++ going
forward. I think "everyone" has migrated - and if not we should force
that migration. (Cloudberry is on SQL++ nowadays, BAD is on SQL++
nowadays, ...) Any objections? If not, I think we should make this
decision officially and stop putting energy into carrying the AQL legacy
around with us. Thoughts?
Re: Time to deprecate AQL?
Posted by Yingyi Bu <bu...@gmail.com>.
+1!
Best,
Yingyi
On Thu, Sep 7, 2017 at 11:44 AM, Michael Carey <mj...@ics.uci.edu> wrote:
> As AsterixDB evolves, and additional features are added - e.g., DISTINCT
> aggregate support, or properly implemented query-bodied functions,
> supporting two query languages is hugely expensive: Updating two grammars,
> parsers, rules, tests, ... IMO it is time to let go of AQL as an externally
> supported interface to AsterixDB and only have SQL++ going forward. I
> think "everyone" has migrated - and if not we should force that migration.
> (Cloudberry is on SQL++ nowadays, BAD is on SQL++ nowadays, ...) Any
> objections? If not, I think we should make this decision officially and
> stop putting energy into carrying the AQL legacy around with us. Thoughts?
>
>
Re: Time to deprecate AQL?
Posted by Xikui Wang <xi...@uci.edu>.
+1!
Best,
Xikui
> On Sep 7, 2017, at 11:49, Gerald Sangudi <sa...@gmail.com> wrote:
>
> :-)
>
> On Sep 7, 2017 11:44 AM, "Michael Carey" <mj...@ics.uci.edu> wrote:
>
> As AsterixDB evolves, and additional features are added - e.g., DISTINCT
> aggregate support, or properly implemented query-bodied functions,
> supporting two query languages is hugely expensive: Updating two grammars,
> parsers, rules, tests, ... IMO it is time to let go of AQL as an externally
> supported interface to AsterixDB and only have SQL++ going forward. I
> think "everyone" has migrated - and if not we should force that migration.
> (Cloudberry is on SQL++ nowadays, BAD is on SQL++ nowadays, ...) Any
> objections? If not, I think we should make this decision officially and
> stop putting energy into carrying the AQL legacy around with us. Thoughts?
Re: Time to deprecate AQL?
Posted by Mike Carey <dt...@gmail.com>.
Or possibly how to retire it and then re-do similarity joins using the
join infrastructure ideas discussed a year or so ago, perhaps. (We
should think about whether or not the time it would take to do SQL+++
might be better used to not use that approach anymore - it was an
interesting experiment at the time it was done, but it's probably worth
having a revisiting discussion 5 years later - and also whether the
algorithm as it was invented is still the preferred one to support -
though the required SQL+++ query would surely be an interesting SQL++
optimizer test... :-))
On 9/7/17 10:21 PM, Chen Li wrote:
> Let's discuss how to move AQL+ to SQL++ after Taewoo comes back.
>
> On Thu, Sep 7, 2017 at 12:10 PM, Taewoo Kim <wa...@gmail.com> wrote:
>
>> For similarity join, we use AQL+ that is based on AQL. I think deprecating
>> (not removing) AQL is OK. Ultimately, AQL+ should be converted to SQL++ :-)
>>
>> Best,
>> Taewoo
>>
>> On Thu, Sep 7, 2017 at 9:04 PM, Steven Jacobs <sj...@ucr.edu> wrote:
>>
>>> I’ll give the BADest +1 I can :)
>>> Steven
>>>
>>> On Thu, Sep 7, 2017 at 8:50 PM Gerald Sangudi <sa...@gmail.com> wrote:
>>>
>>>> :-)
>>>>
>>>> On Sep 7, 2017 11:44 AM, "Michael Carey" <mj...@ics.uci.edu> wrote:
>>>>
>>>> As AsterixDB evolves, and additional features are added - e.g.,
>> DISTINCT
>>>> aggregate support, or properly implemented query-bodied functions,
>>>> supporting two query languages is hugely expensive: Updating two
>>> grammars,
>>>> parsers, rules, tests, ... IMO it is time to let go of AQL as an
>>> externally
>>>> supported interface to AsterixDB and only have SQL++ going forward. I
>>>> think "everyone" has migrated - and if not we should force that
>>> migration.
>>>> (Cloudberry is on SQL++ nowadays, BAD is on SQL++ nowadays, ...) Any
>>>> objections? If not, I think we should make this decision officially
>> and
>>>> stop putting energy into carrying the AQL legacy around with us.
>>> Thoughts?
Re: Time to deprecate AQL?
Posted by Chen Li <ch...@gmail.com>.
Let's discuss how to move AQL+ to SQL++ after Taewoo comes back.
On Thu, Sep 7, 2017 at 12:10 PM, Taewoo Kim <wa...@gmail.com> wrote:
> For similarity join, we use AQL+ that is based on AQL. I think deprecating
> (not removing) AQL is OK. Ultimately, AQL+ should be converted to SQL++ :-)
>
> Best,
> Taewoo
>
> On Thu, Sep 7, 2017 at 9:04 PM, Steven Jacobs <sj...@ucr.edu> wrote:
>
> > I’ll give the BADest +1 I can :)
> > Steven
> >
> > On Thu, Sep 7, 2017 at 8:50 PM Gerald Sangudi <sa...@gmail.com> wrote:
> >
> > > :-)
> > >
> > > On Sep 7, 2017 11:44 AM, "Michael Carey" <mj...@ics.uci.edu> wrote:
> > >
> > > As AsterixDB evolves, and additional features are added - e.g.,
> DISTINCT
> > > aggregate support, or properly implemented query-bodied functions,
> > > supporting two query languages is hugely expensive: Updating two
> > grammars,
> > > parsers, rules, tests, ... IMO it is time to let go of AQL as an
> > externally
> > > supported interface to AsterixDB and only have SQL++ going forward. I
> > > think "everyone" has migrated - and if not we should force that
> > migration.
> > > (Cloudberry is on SQL++ nowadays, BAD is on SQL++ nowadays, ...) Any
> > > objections? If not, I think we should make this decision officially
> and
> > > stop putting energy into carrying the AQL legacy around with us.
> > Thoughts?
> > >
> >
>
Re: Time to deprecate AQL?
Posted by Taewoo Kim <wa...@gmail.com>.
For similarity join, we use AQL+ that is based on AQL. I think deprecating
(not removing) AQL is OK. Ultimately, AQL+ should be converted to SQL++ :-)
Best,
Taewoo
On Thu, Sep 7, 2017 at 9:04 PM, Steven Jacobs <sj...@ucr.edu> wrote:
> I’ll give the BADest +1 I can :)
> Steven
>
> On Thu, Sep 7, 2017 at 8:50 PM Gerald Sangudi <sa...@gmail.com> wrote:
>
> > :-)
> >
> > On Sep 7, 2017 11:44 AM, "Michael Carey" <mj...@ics.uci.edu> wrote:
> >
> > As AsterixDB evolves, and additional features are added - e.g., DISTINCT
> > aggregate support, or properly implemented query-bodied functions,
> > supporting two query languages is hugely expensive: Updating two
> grammars,
> > parsers, rules, tests, ... IMO it is time to let go of AQL as an
> externally
> > supported interface to AsterixDB and only have SQL++ going forward. I
> > think "everyone" has migrated - and if not we should force that
> migration.
> > (Cloudberry is on SQL++ nowadays, BAD is on SQL++ nowadays, ...) Any
> > objections? If not, I think we should make this decision officially and
> > stop putting energy into carrying the AQL legacy around with us.
> Thoughts?
> >
>
Re: Time to deprecate AQL?
Posted by Steven Jacobs <sj...@ucr.edu>.
I’ll give the BADest +1 I can :)
Steven
On Thu, Sep 7, 2017 at 8:50 PM Gerald Sangudi <sa...@gmail.com> wrote:
> :-)
>
> On Sep 7, 2017 11:44 AM, "Michael Carey" <mj...@ics.uci.edu> wrote:
>
> As AsterixDB evolves, and additional features are added - e.g., DISTINCT
> aggregate support, or properly implemented query-bodied functions,
> supporting two query languages is hugely expensive: Updating two grammars,
> parsers, rules, tests, ... IMO it is time to let go of AQL as an externally
> supported interface to AsterixDB and only have SQL++ going forward. I
> think "everyone" has migrated - and if not we should force that migration.
> (Cloudberry is on SQL++ nowadays, BAD is on SQL++ nowadays, ...) Any
> objections? If not, I think we should make this decision officially and
> stop putting energy into carrying the AQL legacy around with us. Thoughts?
>
Re: Time to deprecate AQL?
Posted by Till Westmann <ti...@apache.org>.
I think this seals it :)
> On Sep 7, 2017, at 11:49, Gerald Sangudi <sa...@gmail.com> wrote:
>
> :-)
>
> On Sep 7, 2017 11:44 AM, "Michael Carey" <mj...@ics.uci.edu> wrote:
>
> As AsterixDB evolves, and additional features are added - e.g., DISTINCT
> aggregate support, or properly implemented query-bodied functions,
> supporting two query languages is hugely expensive: Updating two grammars,
> parsers, rules, tests, ... IMO it is time to let go of AQL as an externally
> supported interface to AsterixDB and only have SQL++ going forward. I
> think "everyone" has migrated - and if not we should force that migration.
> (Cloudberry is on SQL++ nowadays, BAD is on SQL++ nowadays, ...) Any
> objections? If not, I think we should make this decision officially and
> stop putting energy into carrying the AQL legacy around with us. Thoughts?
Re: Time to deprecate AQL?
Posted by Gerald Sangudi <sa...@gmail.com>.
:-)
On Sep 7, 2017 11:44 AM, "Michael Carey" <mj...@ics.uci.edu> wrote:
As AsterixDB evolves, and additional features are added - e.g., DISTINCT
aggregate support, or properly implemented query-bodied functions,
supporting two query languages is hugely expensive: Updating two grammars,
parsers, rules, tests, ... IMO it is time to let go of AQL as an externally
supported interface to AsterixDB and only have SQL++ going forward. I
think "everyone" has migrated - and if not we should force that migration.
(Cloudberry is on SQL++ nowadays, BAD is on SQL++ nowadays, ...) Any
objections? If not, I think we should make this decision officially and
stop putting energy into carrying the AQL legacy around with us. Thoughts?