Re: Time to deprecate AQL?
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 Kimwrote: 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 wrote: I’ll give the BADest +1 I can :) Steven On Thu, Sep 7, 2017 at 8:50 PM Gerald Sangudi wrote: :-) On Sep 7, 2017 11:44 AM, "Michael Carey" 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?
Let's discuss how to move AQL+ to SQL++ after Taewoo comes back. On Thu, Sep 7, 2017 at 12:10 PM, Taewoo Kimwrote: > 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 wrote: > > > I’ll give the BADest +1 I can :) > > Steven > > > > On Thu, Sep 7, 2017 at 8:50 PM Gerald Sangudi wrote: > > > > > :-) > > > > > > On Sep 7, 2017 11:44 AM, "Michael Carey" 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?
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 Jacobswrote: > I’ll give the BADest +1 I can :) > Steven > > On Thu, Sep 7, 2017 at 8:50 PM Gerald Sangudi wrote: > > > :-) > > > > On Sep 7, 2017 11:44 AM, "Michael Carey" 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?
+1! Best, Xikui > On Sep 7, 2017, at 11:49, Gerald Sangudiwrote: > > :-) > > On Sep 7, 2017 11:44 AM, "Michael Carey" 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?
:-) On Sep 7, 2017 11:44 AM, "Michael Carey"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?
+1! Best, Yingyi On Thu, Sep 7, 2017 at 11:44 AM, Michael Careywrote: > 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? > >
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?