You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Julian Hyde <jh...@apache.org> on 2014/11/05 05:48:36 UTC
The great renaming
I have a few thoughts on Calcite's development/release schedule for
the next month or so.
First, you saw the announcement of 0.9.1-incubating. That release was
from code that we froze almost a month ago, but it took a while to go
through the two votes, and then a while to get the artifacts posted to
public sites.
Also, we now have a web site. Thanks to Sree for getting that ball
rolling. If you got to http://calcite.incubator.apache.org/ and click
on Releases > 0.9.1-incubating, you should be able to download the
artifacts.
I am working on https://issues.apache.org/jira/browse/CALCITE-296 and
https://issues.apache.org/jira/browse/CALCITE-419, aka the great
renaming. Every package name is changing, and quite a few class names
as well (for instance, FilterRel moves from org.eigenbase.rel to
org.apache.calcite.rel.logical and is renamed to LogicalFilter, while
its base class FilterRelBase moves to org.apache.calcite.rel.core and
is renamed to Filter). We are also going to remove some deprecated
methods and classes. I think our users will have a problem if we
change a lot of names and significantly change functionality.
So, I propose to do a quick release 0.9.2-incubating based on what is
currently in master, merge the renamed packages, and then make a
release of the renamed code without adding a lot of extra
functionality. Because of the renames, I am tempted to call that
release 1.0 beta.
I think we can make a release candidate for 0.9.2 in the next day or
two, then move to a vote.
The web site could also use some work, for example javadoc, and adding
the content currently in the HOWTO, HISTORY and README files. That
could be rolled out with 0.9.2, if someone can get to it in the next
week or so.
If you're working on patches to Calcite code, I won't be inclined to
accept them into 0.9.2 unless they fix critical bugs. And the first
change integrated after 0.9.2 will be the package re-org. For any
other changes, be prepared to integrate the patch (i.e. manually
rebase) into the renamed package structure.
Thoughts on this plan? If it sounds awesome, I'd appreciate some +1s
so I know you're out there.
Julian
Re: The great renaming
Posted by Julian Hyde <ju...@hydromatic.net>.
+1
It looks as if you have done some great work in checkstyle 6.0.1.
I think we already moved to the version with the 'throws indentation'
fix. Because I saw (and fixed) errors about indentation while working
in the calcite-296 branch.
Is 6.0.1 available via the maven plugin? If so go ahead and submit a
patch that uses it. I will apply to my calcite-296 branch, so it will
all go into master together.
Julian
On Sun, Nov 9, 2014 at 12:53 PM, Vladimir Sitnikov
<si...@gmail.com> wrote:
> What do you think if we upgrade checkstyle plugin as well?
>
> I have two reasons for that upgrade:
> 1) We would eventually upgrade anyway, thus it is better to upgrade
> during this renaming. I remember never versions of checkstyle had
> different understanding of "throws indentation"
> 2) checkstyle 6.0.1 includes a performance fix, so the check is
> performed faster, meaning faster development turnaround:
> https://github.com/checkstyle/checkstyle/commit/d879f868146f66617389b6ce6354f2adbef4a79d
>
> Vladimir
Re: The great renaming
Posted by Vladimir Sitnikov <si...@gmail.com>.
What do you think if we upgrade checkstyle plugin as well?
I have two reasons for that upgrade:
1) We would eventually upgrade anyway, thus it is better to upgrade
during this renaming. I remember never versions of checkstyle had
different understanding of "throws indentation"
2) checkstyle 6.0.1 includes a performance fix, so the check is
performed faster, meaning faster development turnaround:
https://github.com/checkstyle/checkstyle/commit/d879f868146f66617389b6ce6354f2adbef4a79d
Vladimir
Re: The great renaming
Posted by Julian Hyde <ju...@hydromatic.net>.
Andrew,
I’ve implemented these suggestions. I put AggregateFunction (and in fact everything that was in org.apache.calcite except DataContext) into the new schema package because functions, like schemas, tables and columns, form the namespace that the validator uses to validate SQL queries. That is the purpose of the schema SPI.
The classes in org.apache.calcite.impl moved to org.apache.calcite.schema.impl.
And org.apache.calcite.impl.interpreter became org.apache.calcite.interpreter because it is a pretty significant feature.
I have posted the new javadoc at http://www.hydromatic.net/calcite-296/apidocs/overview-summary.html
Julian
On Nov 5, 2014, at 5:36 PM, andrew <an...@primer.org> wrote:
> My notes:
>
> 1. org/apache/calcite/impl/enumerable/impl/package-summary.html still refers to ‘Optiq’.
>
>> Are the package names intuitive? For example, should I rename org.apache.calcite.impl to org.apache.calcite.adapters?
>
> 2. Yes, org.apache.calcite.adapters is more readable.
>
>> Since most of the classes under org.apache.calcite (Table, Schema etc.) form the metadata SPI, should I move them to a new package org.apache.calcite.schema?
>
> 3. For the most part, yes, agree with putting classes under .schema. However, some things like the AggregateFunction and ImplementableFunction interfaces would seem to be better not placed in .schema, at least it’s not obvious why function impl’s are schema-related.
>
>> There’s still time to rename things.
>>
>> To see the renames, look at the git log: https://github.com/julianhyde/incubator-calcite/commit/afbe561483c87acf8ab8a1965f48980b09e1207a.
>>
>> Julian
>>
>> On Nov 5, 2014, at 11:22 AM, andrew <an...@primer.org> wrote:
>>
>>> Thank you Julian! This will make working with Calcite so much easier, especially the changes to enumerable.
>>>
>>>
>>>> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com> wrote:
>>>>
>>>> I’m structuring it as (a) a commit that renames / moves / deletes files only (no content changes in the files), (b) a commit that fixes up class names, package names, and imposes the new rule for import ordering. I may have removed one or two deprecated methods and classes in (b), but not many.
>>>>
>>>> I’ve most finished (b) and will check into my calcite-296 branch today.
>>>>
>>>> Then will come (c) moving the “enumerable” adapter (formerly net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java, now org.apache.calcite.impl.enumerable) into a new module.
>>>>
>>>> Julian
>>>>
>>>>
>>>> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>>>>
>>>>>> I'm inclined to change names initially. Then step two is any class deletes
>>>>>> or method sig changes.
>>>>>
>>>>> I like the idea to perform renames (e.g. renames of packages, classes)
>>>>> and signature changes (e.g. adding new constructor parameters) in
>>>>> different commits.
>>>>>
>>>>> Anyway, +1 for rolling the renames.
>>>>>
>>>>> --
>>>>> Vladimir
>>>>
>>>
>>
>
Re: The great renaming
Posted by andrew <an...@primer.org>.
My notes:
1. org/apache/calcite/impl/enumerable/impl/package-summary.html still refers to ‘Optiq’.
> Are the package names intuitive? For example, should I rename org.apache.calcite.impl to org.apache.calcite.adapters?
2. Yes, org.apache.calcite.adapters is more readable.
> Since most of the classes under org.apache.calcite (Table, Schema etc.) form the metadata SPI, should I move them to a new package org.apache.calcite.schema?
3. For the most part, yes, agree with putting classes under .schema. However, some things like the AggregateFunction and ImplementableFunction interfaces would seem to be better not placed in .schema, at least it’s not obvious why function impl’s are schema-related.
> There’s still time to rename things.
>
> To see the renames, look at the git log: https://github.com/julianhyde/incubator-calcite/commit/afbe561483c87acf8ab8a1965f48980b09e1207a.
>
> Julian
>
> On Nov 5, 2014, at 11:22 AM, andrew <an...@primer.org> wrote:
>
>> Thank you Julian! This will make working with Calcite so much easier, especially the changes to enumerable.
>>
>>
>>> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com> wrote:
>>>
>>> I’m structuring it as (a) a commit that renames / moves / deletes files only (no content changes in the files), (b) a commit that fixes up class names, package names, and imposes the new rule for import ordering. I may have removed one or two deprecated methods and classes in (b), but not many.
>>>
>>> I’ve most finished (b) and will check into my calcite-296 branch today.
>>>
>>> Then will come (c) moving the “enumerable” adapter (formerly net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java, now org.apache.calcite.impl.enumerable) into a new module.
>>>
>>> Julian
>>>
>>>
>>> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>>>
>>>>> I'm inclined to change names initially. Then step two is any class deletes
>>>>> or method sig changes.
>>>>
>>>> I like the idea to perform renames (e.g. renames of packages, classes)
>>>> and signature changes (e.g. adding new constructor parameters) in
>>>> different commits.
>>>>
>>>> Anyway, +1 for rolling the renames.
>>>>
>>>> --
>>>> Vladimir
>>>
>>
>
Re: The great renaming
Posted by Vladimir Sitnikov <si...@gmail.com>.
It is a final class, so it does not have lots of implementations.
Ok, got the idea.
Regards,
Vladimir Sitnikov
15 нояб. 2014 г. 22:03 пользователь "Julian Hyde" <ju...@hydromatic.net>
написал:
> Since there were no implementations of it, I didn't bother creating a base
> class. You're welcome to re-organize things if you create an
> EnumerableCorrelator. Or maybe it should be called "Correlate" since
> RelNodes are verbs now.
>
> There probably aren't many implementations so you shouldn't worry about
> breaking stuff.
>
> Julian
>
> > On Nov 15, 2014, at 09:41, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
> >
> > Is there a reason Correlator is not named LogicalCorrelator?
> >
> > As far as I understand, it should be placed in
> > org.apache.calcite.rel.logical and named LogicalCorrelator to be in
> > line with other Logical* rels.
> >
> > Vladimir
>
Re: The great renaming
Posted by Julian Hyde <ju...@hydromatic.net>.
Since there were no implementations of it, I didn't bother creating a base class. You're welcome to re-organize things if you create an EnumerableCorrelator. Or maybe it should be called "Correlate" since RelNodes are verbs now.
There probably aren't many implementations so you shouldn't worry about breaking stuff.
Julian
> On Nov 15, 2014, at 09:41, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> Is there a reason Correlator is not named LogicalCorrelator?
>
> As far as I understand, it should be placed in
> org.apache.calcite.rel.logical and named LogicalCorrelator to be in
> line with other Logical* rels.
>
> Vladimir
Re: The great renaming
Posted by Vladimir Sitnikov <si...@gmail.com>.
Is there a reason Correlator is not named LogicalCorrelator?
As far as I understand, it should be placed in
org.apache.calcite.rel.logical and named LogicalCorrelator to be in
line with other Logical* rels.
Vladimir
Re: The great renaming
Posted by Julian Hyde <ju...@gmail.com>.
Those of you who subscribe to the commits mailing list may have just noticed a lot of spam descending on your inbox. Yes, the Great Renaming is done.
The changes are described in detail in https://issues.apache.org/jira/secure/attachment/12681620/mapping.txt.
Issues fixed:
* https://issues.apache.org/jira/browse/CALCITE-296 Re-organize package structure
* https://issues.apache.org/jira/browse/CALCITE-419 Naming convention for planner rules
* https://issues.apache.org/jira/browse/CALCITE-306 Standardize code style for "import package.*;"
* https://issues.apache.org/jira/browse/CALCITE-465 Remove OneRow and Empty relational expressions; Values will suffice
Remaining work:
* https://issues.apache.org/jira/browse/CALCITE-466 Move the "enumerable" adapter out of core
There are other cases in this batch of changes that cause significant API changes:
* https://issues.apache.org/jira/browse/CALCITE-460 Add ImmutableBitSet and replace uses of BitSet
* https://issues.apache.org/jira/browse/CALCITE-370 Support GROUPING SETS, CUBE, ROLLUP in SQL and algebra
Master branch is now stable. Since it will be hard to port patches developed against the old namespace, I strongly encourage you to update to the latest master as soon as possible, and do all future work in the new namespace.
Julian
> On Nov 13, 2014, at 5:30 PM, Aman Sinha <as...@maprtech.com> wrote:
>
> Sounds reasonable. +1
>
> On Thu, Nov 13, 2014 at 1:47 PM, Julian Hyde <ju...@gmail.com> wrote:
>
>> I see the point of including the “type” in class names; and we still do
>> this for sub-classes of SqlNode, RexNode. But relational operators are the
>> main thing Calcite does, and are used in several ways (e.g. Filter is
>> subclassed as DrillFilter, and combined with another operator in
>> FilterAggregateTransposeRule) so I decided to keep them short. (I didn’t
>> want to be creating rules called FilterRelAggregateRelTransposeRule.)
>>
>> Even if I agreed, it would be another couple of days to change them all
>> back, so it isn’t going to happen. :)
>>
>> Note that operator names tend to be verbs (aggregate, scan, filter,
>> project).
>>
>> A few base classes and interfaces don’t follow this convention: RelNode,
>> AbstractRelNode, SingleRel, EnumerableRel, JdbcRel.
>>
>> I removed one cause of confusion: I obsoleted Aggregation (base class of
>> SqlCountAggFunction, etc.). You can now use SqlAggFunction in all cases.
>>
>> Regarding ‘Remove’ rules. I don’t think there are still any rules with
>> Remove at the start. But I take your point. I wasn’t able to apply the rule
>> naming convention to rules that apply to a lot of types of rels, e.g.
>> ReduceDecimalsRule, EnumerableConverterRule. I figured it wasn’t good to
>> slavishly follow the convention.
>>
>> Julian
>>
>>
>> On Nov 13, 2014, at 7:05 AM, Jacques Nadeau <ja...@apache.org> wrote:
>>
>>> Hey Aman,
>>>
>>> I agree with generic naming. Calling something "aggregate" in the
>> context
>>> of a query engine seems very generic
>>>
>>> +1 for AggregateRel etc.
>>> On Nov 12, 2014 9:53 PM, "Aman Sinha" <as...@maprtech.com> wrote:
>>>
>>>> A couple of comments (I understand these are late but just wanted to put
>>>> them out anyways):
>>>>
>>>> I would have preferred the names of the base rels to be FilterRel,
>>>> AggregateRel etc instead of simply Filter, Aggregate etc. An
>> 'Aggregate'
>>>> could be an
>>>> aggregate function or a rel that operates on rows of data.
>>>>
>>>> Regarding the planner rules renaming, some rules still have the verb at
>>>> the beginning .. e.g the 'Remove*' rules which is not consistent with
>> the
>>>> naming convention described in CALCITE-419.
>>>>
>>>> Aman
>>>>
>>>>
>>>> On Wed, Nov 12, 2014 at 2:25 PM, Julian Hyde <ju...@gmail.com>
>> wrote:
>>>>
>>>>> An update.
>>>>>
>>>>> Release 0.9.2 is almost through the Apache Incubator PMC vote process
>>>>> (fingers crossed!) so if all goes well we should be able to release
>>>>> tonight. Then I'd like to check the changes into master ASAP.
>>>>>
>>>>> A reminder that today is the deadline for review comments. If if no
>>>>> show-stoppers come up, I'll check in tomorrow (rebasing and squashing
>>>> what
>>>>> is in
>>>>>
>>>>
>> https://github.com/julianhyde/incubator-calcite/commit/67c6940b6845c5223ed9870efb58e97c4967aa70
>>>>> ).
>>>>>
>>>>> I'll also produce a document that describes the before:after name
>>>> mapping.
>>>>>
>>>>> Julian
>>>>>
>>>>>
>>>>>
>>>>>> On Nov 6, 2014, at 10:21 AM, Julian Hyde <ju...@hydromatic.net>
>>>> wrote:
>>>>>>
>>>>>> A week for feedback is perfectly reasonable. However, feel free to
>>>>> provide feedback earlier. I think we will go through several iterations
>>>>> before we are ready to call this 1.0. If most people can provide their
>>>>> feedback within a day or so, we can get through those iterations
>> faster.
>>>>>>
>>>>>> I already have Andrew’s feedback and will be fixing it in the next day
>>>>> or so.
>>>>>>
>>>>>> Julian
>>>>>>
>>>>>>
>>>>>> On Nov 5, 2014, at 9:20 PM, Jacques Nadeau <ja...@apache.org>
>> wrote:
>>>>>>
>>>>>>> Given that these are fairly important decisions, I'd request a
>> lengthy
>>>>> time
>>>>>>> to review the changes and provide feedback. I will also make sure
>> that
>>>>>>> everyone on my team also reviews and provides feedback.
>>>>>>>
>>>>>>> Can we set a deadline of Wednesday the 12th for feedback?
>>>>>>>
>>>>>>> Thanks again for all your hard work Julian.
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> On Wed, Nov 5, 2014 at 3:14 PM, Julian Hyde <ju...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>>> I have completed phases (a) and (b), and I’ve posted the generated
>>>>>>>> javadocs to http://www.hydromatic.net/calcite-296/apidocs/.
>>>>>>>>
>>>>>>>> I’d appreciate reviews.
>>>>>>>> Are the package names intuitive? For example, should I rename
>>>>>>>> org.apache.calcite.impl to org.apache.calcite.adapters?
>>>>>>>> Since most of the classes under org.apache.calcite (Table, Schema
>>>> etc.)
>>>>>>>> form the metadata SPI, should I move them to a new package
>>>>>>>> org.apache.calcite.schema?
>>>>>>>>
>>>>>>>> There’s still time to rename things.
>>>>>>>>
>>>>>>>> To see the renames, look at the git log:
>>>>>>>>
>>>>>
>>>>
>> https://github.com/julianhyde/incubator-calcite/commit/afbe561483c87acf8ab8a1965f48980b09e1207a
>>>>>>>> .
>>>>>>>>
>>>>>>>> Julian
>>>>>>>>
>>>>>>>> On Nov 5, 2014, at 11:22 AM, andrew <an...@primer.org> wrote:
>>>>>>>>
>>>>>>>>> Thank you Julian! This will make working with Calcite so much
>>>> easier,
>>>>>>>> especially the changes to enumerable.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com>
>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I’m structuring it as (a) a commit that renames / moves / deletes
>>>>> files
>>>>>>>> only (no content changes in the files), (b) a commit that fixes up
>>>>> class
>>>>>>>> names, package names, and imposes the new rule for import ordering.
>> I
>>>>> may
>>>>>>>> have removed one or two deprecated methods and classes in (b), but
>>>> not
>>>>> many.
>>>>>>>>>>
>>>>>>>>>> I’ve most finished (b) and will check into my calcite-296 branch
>>>>> today.
>>>>>>>>>>
>>>>>>>>>> Then will come (c) moving the “enumerable” adapter (formerly
>>>>>>>> net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java,
>>>> now
>>>>>>>> org.apache.calcite.impl.enumerable) into a new module.
>>>>>>>>>>
>>>>>>>>>> Julian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <
>>>>>>>> sitnikov.vladimir@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>> I'm inclined to change names initially. Then step two is any
>>>> class
>>>>>>>> deletes
>>>>>>>>>>>> or method sig changes.
>>>>>>>>>>>
>>>>>>>>>>> I like the idea to perform renames (e.g. renames of packages,
>>>>> classes)
>>>>>>>>>>> and signature changes (e.g. adding new constructor parameters) in
>>>>>>>>>>> different commits.
>>>>>>>>>>>
>>>>>>>>>>> Anyway, +1 for rolling the renames.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Vladimir
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
Re: The great renaming
Posted by Aman Sinha <as...@maprtech.com>.
Sounds reasonable. +1
On Thu, Nov 13, 2014 at 1:47 PM, Julian Hyde <ju...@gmail.com> wrote:
> I see the point of including the “type” in class names; and we still do
> this for sub-classes of SqlNode, RexNode. But relational operators are the
> main thing Calcite does, and are used in several ways (e.g. Filter is
> subclassed as DrillFilter, and combined with another operator in
> FilterAggregateTransposeRule) so I decided to keep them short. (I didn’t
> want to be creating rules called FilterRelAggregateRelTransposeRule.)
>
> Even if I agreed, it would be another couple of days to change them all
> back, so it isn’t going to happen. :)
>
> Note that operator names tend to be verbs (aggregate, scan, filter,
> project).
>
> A few base classes and interfaces don’t follow this convention: RelNode,
> AbstractRelNode, SingleRel, EnumerableRel, JdbcRel.
>
> I removed one cause of confusion: I obsoleted Aggregation (base class of
> SqlCountAggFunction, etc.). You can now use SqlAggFunction in all cases.
>
> Regarding ‘Remove’ rules. I don’t think there are still any rules with
> Remove at the start. But I take your point. I wasn’t able to apply the rule
> naming convention to rules that apply to a lot of types of rels, e.g.
> ReduceDecimalsRule, EnumerableConverterRule. I figured it wasn’t good to
> slavishly follow the convention.
>
> Julian
>
>
> On Nov 13, 2014, at 7:05 AM, Jacques Nadeau <ja...@apache.org> wrote:
>
> > Hey Aman,
> >
> > I agree with generic naming. Calling something "aggregate" in the
> context
> > of a query engine seems very generic
> >
> > +1 for AggregateRel etc.
> > On Nov 12, 2014 9:53 PM, "Aman Sinha" <as...@maprtech.com> wrote:
> >
> >> A couple of comments (I understand these are late but just wanted to put
> >> them out anyways):
> >>
> >> I would have preferred the names of the base rels to be FilterRel,
> >> AggregateRel etc instead of simply Filter, Aggregate etc. An
> 'Aggregate'
> >> could be an
> >> aggregate function or a rel that operates on rows of data.
> >>
> >> Regarding the planner rules renaming, some rules still have the verb at
> >> the beginning .. e.g the 'Remove*' rules which is not consistent with
> the
> >> naming convention described in CALCITE-419.
> >>
> >> Aman
> >>
> >>
> >> On Wed, Nov 12, 2014 at 2:25 PM, Julian Hyde <ju...@gmail.com>
> wrote:
> >>
> >>> An update.
> >>>
> >>> Release 0.9.2 is almost through the Apache Incubator PMC vote process
> >>> (fingers crossed!) so if all goes well we should be able to release
> >>> tonight. Then I'd like to check the changes into master ASAP.
> >>>
> >>> A reminder that today is the deadline for review comments. If if no
> >>> show-stoppers come up, I'll check in tomorrow (rebasing and squashing
> >> what
> >>> is in
> >>>
> >>
> https://github.com/julianhyde/incubator-calcite/commit/67c6940b6845c5223ed9870efb58e97c4967aa70
> >>> ).
> >>>
> >>> I'll also produce a document that describes the before:after name
> >> mapping.
> >>>
> >>> Julian
> >>>
> >>>
> >>>
> >>>> On Nov 6, 2014, at 10:21 AM, Julian Hyde <ju...@hydromatic.net>
> >> wrote:
> >>>>
> >>>> A week for feedback is perfectly reasonable. However, feel free to
> >>> provide feedback earlier. I think we will go through several iterations
> >>> before we are ready to call this 1.0. If most people can provide their
> >>> feedback within a day or so, we can get through those iterations
> faster.
> >>>>
> >>>> I already have Andrew’s feedback and will be fixing it in the next day
> >>> or so.
> >>>>
> >>>> Julian
> >>>>
> >>>>
> >>>> On Nov 5, 2014, at 9:20 PM, Jacques Nadeau <ja...@apache.org>
> wrote:
> >>>>
> >>>>> Given that these are fairly important decisions, I'd request a
> lengthy
> >>> time
> >>>>> to review the changes and provide feedback. I will also make sure
> that
> >>>>> everyone on my team also reviews and provides feedback.
> >>>>>
> >>>>> Can we set a deadline of Wednesday the 12th for feedback?
> >>>>>
> >>>>> Thanks again for all your hard work Julian.
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>>> On Wed, Nov 5, 2014 at 3:14 PM, Julian Hyde <ju...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>>> I have completed phases (a) and (b), and I’ve posted the generated
> >>>>>> javadocs to http://www.hydromatic.net/calcite-296/apidocs/.
> >>>>>>
> >>>>>> I’d appreciate reviews.
> >>>>>> Are the package names intuitive? For example, should I rename
> >>>>>> org.apache.calcite.impl to org.apache.calcite.adapters?
> >>>>>> Since most of the classes under org.apache.calcite (Table, Schema
> >> etc.)
> >>>>>> form the metadata SPI, should I move them to a new package
> >>>>>> org.apache.calcite.schema?
> >>>>>>
> >>>>>> There’s still time to rename things.
> >>>>>>
> >>>>>> To see the renames, look at the git log:
> >>>>>>
> >>>
> >>
> https://github.com/julianhyde/incubator-calcite/commit/afbe561483c87acf8ab8a1965f48980b09e1207a
> >>>>>> .
> >>>>>>
> >>>>>> Julian
> >>>>>>
> >>>>>> On Nov 5, 2014, at 11:22 AM, andrew <an...@primer.org> wrote:
> >>>>>>
> >>>>>>> Thank you Julian! This will make working with Calcite so much
> >> easier,
> >>>>>> especially the changes to enumerable.
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com>
> >>> wrote:
> >>>>>>>>
> >>>>>>>> I’m structuring it as (a) a commit that renames / moves / deletes
> >>> files
> >>>>>> only (no content changes in the files), (b) a commit that fixes up
> >>> class
> >>>>>> names, package names, and imposes the new rule for import ordering.
> I
> >>> may
> >>>>>> have removed one or two deprecated methods and classes in (b), but
> >> not
> >>> many.
> >>>>>>>>
> >>>>>>>> I’ve most finished (b) and will check into my calcite-296 branch
> >>> today.
> >>>>>>>>
> >>>>>>>> Then will come (c) moving the “enumerable” adapter (formerly
> >>>>>> net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java,
> >> now
> >>>>>> org.apache.calcite.impl.enumerable) into a new module.
> >>>>>>>>
> >>>>>>>> Julian
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <
> >>>>>> sitnikov.vladimir@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>>> I'm inclined to change names initially. Then step two is any
> >> class
> >>>>>> deletes
> >>>>>>>>>> or method sig changes.
> >>>>>>>>>
> >>>>>>>>> I like the idea to perform renames (e.g. renames of packages,
> >>> classes)
> >>>>>>>>> and signature changes (e.g. adding new constructor parameters) in
> >>>>>>>>> different commits.
> >>>>>>>>>
> >>>>>>>>> Anyway, +1 for rolling the renames.
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Vladimir
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
> >>
>
>
Re: The great renaming
Posted by Julian Hyde <ju...@gmail.com>.
I see the point of including the “type” in class names; and we still do this for sub-classes of SqlNode, RexNode. But relational operators are the main thing Calcite does, and are used in several ways (e.g. Filter is subclassed as DrillFilter, and combined with another operator in FilterAggregateTransposeRule) so I decided to keep them short. (I didn’t want to be creating rules called FilterRelAggregateRelTransposeRule.)
Even if I agreed, it would be another couple of days to change them all back, so it isn’t going to happen. :)
Note that operator names tend to be verbs (aggregate, scan, filter, project).
A few base classes and interfaces don’t follow this convention: RelNode, AbstractRelNode, SingleRel, EnumerableRel, JdbcRel.
I removed one cause of confusion: I obsoleted Aggregation (base class of SqlCountAggFunction, etc.). You can now use SqlAggFunction in all cases.
Regarding ‘Remove’ rules. I don’t think there are still any rules with Remove at the start. But I take your point. I wasn’t able to apply the rule naming convention to rules that apply to a lot of types of rels, e.g. ReduceDecimalsRule, EnumerableConverterRule. I figured it wasn’t good to slavishly follow the convention.
Julian
On Nov 13, 2014, at 7:05 AM, Jacques Nadeau <ja...@apache.org> wrote:
> Hey Aman,
>
> I agree with generic naming. Calling something "aggregate" in the context
> of a query engine seems very generic
>
> +1 for AggregateRel etc.
> On Nov 12, 2014 9:53 PM, "Aman Sinha" <as...@maprtech.com> wrote:
>
>> A couple of comments (I understand these are late but just wanted to put
>> them out anyways):
>>
>> I would have preferred the names of the base rels to be FilterRel,
>> AggregateRel etc instead of simply Filter, Aggregate etc. An 'Aggregate'
>> could be an
>> aggregate function or a rel that operates on rows of data.
>>
>> Regarding the planner rules renaming, some rules still have the verb at
>> the beginning .. e.g the 'Remove*' rules which is not consistent with the
>> naming convention described in CALCITE-419.
>>
>> Aman
>>
>>
>> On Wed, Nov 12, 2014 at 2:25 PM, Julian Hyde <ju...@gmail.com> wrote:
>>
>>> An update.
>>>
>>> Release 0.9.2 is almost through the Apache Incubator PMC vote process
>>> (fingers crossed!) so if all goes well we should be able to release
>>> tonight. Then I'd like to check the changes into master ASAP.
>>>
>>> A reminder that today is the deadline for review comments. If if no
>>> show-stoppers come up, I'll check in tomorrow (rebasing and squashing
>> what
>>> is in
>>>
>> https://github.com/julianhyde/incubator-calcite/commit/67c6940b6845c5223ed9870efb58e97c4967aa70
>>> ).
>>>
>>> I'll also produce a document that describes the before:after name
>> mapping.
>>>
>>> Julian
>>>
>>>
>>>
>>>> On Nov 6, 2014, at 10:21 AM, Julian Hyde <ju...@hydromatic.net>
>> wrote:
>>>>
>>>> A week for feedback is perfectly reasonable. However, feel free to
>>> provide feedback earlier. I think we will go through several iterations
>>> before we are ready to call this 1.0. If most people can provide their
>>> feedback within a day or so, we can get through those iterations faster.
>>>>
>>>> I already have Andrew’s feedback and will be fixing it in the next day
>>> or so.
>>>>
>>>> Julian
>>>>
>>>>
>>>> On Nov 5, 2014, at 9:20 PM, Jacques Nadeau <ja...@apache.org> wrote:
>>>>
>>>>> Given that these are fairly important decisions, I'd request a lengthy
>>> time
>>>>> to review the changes and provide feedback. I will also make sure that
>>>>> everyone on my team also reviews and provides feedback.
>>>>>
>>>>> Can we set a deadline of Wednesday the 12th for feedback?
>>>>>
>>>>> Thanks again for all your hard work Julian.
>>>>>
>>>>> Jacques
>>>>>
>>>>> On Wed, Nov 5, 2014 at 3:14 PM, Julian Hyde <ju...@gmail.com>
>>> wrote:
>>>>>
>>>>>> I have completed phases (a) and (b), and I’ve posted the generated
>>>>>> javadocs to http://www.hydromatic.net/calcite-296/apidocs/.
>>>>>>
>>>>>> I’d appreciate reviews.
>>>>>> Are the package names intuitive? For example, should I rename
>>>>>> org.apache.calcite.impl to org.apache.calcite.adapters?
>>>>>> Since most of the classes under org.apache.calcite (Table, Schema
>> etc.)
>>>>>> form the metadata SPI, should I move them to a new package
>>>>>> org.apache.calcite.schema?
>>>>>>
>>>>>> There’s still time to rename things.
>>>>>>
>>>>>> To see the renames, look at the git log:
>>>>>>
>>>
>> https://github.com/julianhyde/incubator-calcite/commit/afbe561483c87acf8ab8a1965f48980b09e1207a
>>>>>> .
>>>>>>
>>>>>> Julian
>>>>>>
>>>>>> On Nov 5, 2014, at 11:22 AM, andrew <an...@primer.org> wrote:
>>>>>>
>>>>>>> Thank you Julian! This will make working with Calcite so much
>> easier,
>>>>>> especially the changes to enumerable.
>>>>>>>
>>>>>>>
>>>>>>>> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com>
>>> wrote:
>>>>>>>>
>>>>>>>> I’m structuring it as (a) a commit that renames / moves / deletes
>>> files
>>>>>> only (no content changes in the files), (b) a commit that fixes up
>>> class
>>>>>> names, package names, and imposes the new rule for import ordering. I
>>> may
>>>>>> have removed one or two deprecated methods and classes in (b), but
>> not
>>> many.
>>>>>>>>
>>>>>>>> I’ve most finished (b) and will check into my calcite-296 branch
>>> today.
>>>>>>>>
>>>>>>>> Then will come (c) moving the “enumerable” adapter (formerly
>>>>>> net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java,
>> now
>>>>>> org.apache.calcite.impl.enumerable) into a new module.
>>>>>>>>
>>>>>>>> Julian
>>>>>>>>
>>>>>>>>
>>>>>>>> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <
>>>>>> sitnikov.vladimir@gmail.com> wrote:
>>>>>>>>
>>>>>>>>>> I'm inclined to change names initially. Then step two is any
>> class
>>>>>> deletes
>>>>>>>>>> or method sig changes.
>>>>>>>>>
>>>>>>>>> I like the idea to perform renames (e.g. renames of packages,
>>> classes)
>>>>>>>>> and signature changes (e.g. adding new constructor parameters) in
>>>>>>>>> different commits.
>>>>>>>>>
>>>>>>>>> Anyway, +1 for rolling the renames.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
Re: The great renaming
Posted by Jacques Nadeau <ja...@apache.org>.
Hey Aman,
I agree with generic naming. Calling something "aggregate" in the context
of a query engine seems very generic
+1 for AggregateRel etc.
On Nov 12, 2014 9:53 PM, "Aman Sinha" <as...@maprtech.com> wrote:
> A couple of comments (I understand these are late but just wanted to put
> them out anyways):
>
> I would have preferred the names of the base rels to be FilterRel,
> AggregateRel etc instead of simply Filter, Aggregate etc. An 'Aggregate'
> could be an
> aggregate function or a rel that operates on rows of data.
>
> Regarding the planner rules renaming, some rules still have the verb at
> the beginning .. e.g the 'Remove*' rules which is not consistent with the
> naming convention described in CALCITE-419.
>
> Aman
>
>
> On Wed, Nov 12, 2014 at 2:25 PM, Julian Hyde <ju...@gmail.com> wrote:
>
> > An update.
> >
> > Release 0.9.2 is almost through the Apache Incubator PMC vote process
> > (fingers crossed!) so if all goes well we should be able to release
> > tonight. Then I'd like to check the changes into master ASAP.
> >
> > A reminder that today is the deadline for review comments. If if no
> > show-stoppers come up, I'll check in tomorrow (rebasing and squashing
> what
> > is in
> >
> https://github.com/julianhyde/incubator-calcite/commit/67c6940b6845c5223ed9870efb58e97c4967aa70
> > ).
> >
> > I'll also produce a document that describes the before:after name
> mapping.
> >
> > Julian
> >
> >
> >
> > > On Nov 6, 2014, at 10:21 AM, Julian Hyde <ju...@hydromatic.net>
> wrote:
> > >
> > > A week for feedback is perfectly reasonable. However, feel free to
> > provide feedback earlier. I think we will go through several iterations
> > before we are ready to call this 1.0. If most people can provide their
> > feedback within a day or so, we can get through those iterations faster.
> > >
> > > I already have Andrew’s feedback and will be fixing it in the next day
> > or so.
> > >
> > > Julian
> > >
> > >
> > > On Nov 5, 2014, at 9:20 PM, Jacques Nadeau <ja...@apache.org> wrote:
> > >
> > >> Given that these are fairly important decisions, I'd request a lengthy
> > time
> > >> to review the changes and provide feedback. I will also make sure that
> > >> everyone on my team also reviews and provides feedback.
> > >>
> > >> Can we set a deadline of Wednesday the 12th for feedback?
> > >>
> > >> Thanks again for all your hard work Julian.
> > >>
> > >> Jacques
> > >>
> > >> On Wed, Nov 5, 2014 at 3:14 PM, Julian Hyde <ju...@gmail.com>
> > wrote:
> > >>
> > >>> I have completed phases (a) and (b), and I’ve posted the generated
> > >>> javadocs to http://www.hydromatic.net/calcite-296/apidocs/.
> > >>>
> > >>> I’d appreciate reviews.
> > >>> Are the package names intuitive? For example, should I rename
> > >>> org.apache.calcite.impl to org.apache.calcite.adapters?
> > >>> Since most of the classes under org.apache.calcite (Table, Schema
> etc.)
> > >>> form the metadata SPI, should I move them to a new package
> > >>> org.apache.calcite.schema?
> > >>>
> > >>> There’s still time to rename things.
> > >>>
> > >>> To see the renames, look at the git log:
> > >>>
> >
> https://github.com/julianhyde/incubator-calcite/commit/afbe561483c87acf8ab8a1965f48980b09e1207a
> > >>> .
> > >>>
> > >>> Julian
> > >>>
> > >>> On Nov 5, 2014, at 11:22 AM, andrew <an...@primer.org> wrote:
> > >>>
> > >>>> Thank you Julian! This will make working with Calcite so much
> easier,
> > >>> especially the changes to enumerable.
> > >>>>
> > >>>>
> > >>>>> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com>
> > wrote:
> > >>>>>
> > >>>>> I’m structuring it as (a) a commit that renames / moves / deletes
> > files
> > >>> only (no content changes in the files), (b) a commit that fixes up
> > class
> > >>> names, package names, and imposes the new rule for import ordering. I
> > may
> > >>> have removed one or two deprecated methods and classes in (b), but
> not
> > many.
> > >>>>>
> > >>>>> I’ve most finished (b) and will check into my calcite-296 branch
> > today.
> > >>>>>
> > >>>>> Then will come (c) moving the “enumerable” adapter (formerly
> > >>> net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java,
> now
> > >>> org.apache.calcite.impl.enumerable) into a new module.
> > >>>>>
> > >>>>> Julian
> > >>>>>
> > >>>>>
> > >>>>> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <
> > >>> sitnikov.vladimir@gmail.com> wrote:
> > >>>>>
> > >>>>>>> I'm inclined to change names initially. Then step two is any
> class
> > >>> deletes
> > >>>>>>> or method sig changes.
> > >>>>>>
> > >>>>>> I like the idea to perform renames (e.g. renames of packages,
> > classes)
> > >>>>>> and signature changes (e.g. adding new constructor parameters) in
> > >>>>>> different commits.
> > >>>>>>
> > >>>>>> Anyway, +1 for rolling the renames.
> > >>>>>>
> > >>>>>> --
> > >>>>>> Vladimir
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >
> >
> >
>
Re: The great renaming
Posted by Aman Sinha <as...@maprtech.com>.
A couple of comments (I understand these are late but just wanted to put
them out anyways):
I would have preferred the names of the base rels to be FilterRel,
AggregateRel etc instead of simply Filter, Aggregate etc. An 'Aggregate'
could be an
aggregate function or a rel that operates on rows of data.
Regarding the planner rules renaming, some rules still have the verb at
the beginning .. e.g the 'Remove*' rules which is not consistent with the
naming convention described in CALCITE-419.
Aman
On Wed, Nov 12, 2014 at 2:25 PM, Julian Hyde <ju...@gmail.com> wrote:
> An update.
>
> Release 0.9.2 is almost through the Apache Incubator PMC vote process
> (fingers crossed!) so if all goes well we should be able to release
> tonight. Then I'd like to check the changes into master ASAP.
>
> A reminder that today is the deadline for review comments. If if no
> show-stoppers come up, I'll check in tomorrow (rebasing and squashing what
> is in
> https://github.com/julianhyde/incubator-calcite/commit/67c6940b6845c5223ed9870efb58e97c4967aa70
> ).
>
> I'll also produce a document that describes the before:after name mapping.
>
> Julian
>
>
>
> > On Nov 6, 2014, at 10:21 AM, Julian Hyde <ju...@hydromatic.net> wrote:
> >
> > A week for feedback is perfectly reasonable. However, feel free to
> provide feedback earlier. I think we will go through several iterations
> before we are ready to call this 1.0. If most people can provide their
> feedback within a day or so, we can get through those iterations faster.
> >
> > I already have Andrew’s feedback and will be fixing it in the next day
> or so.
> >
> > Julian
> >
> >
> > On Nov 5, 2014, at 9:20 PM, Jacques Nadeau <ja...@apache.org> wrote:
> >
> >> Given that these are fairly important decisions, I'd request a lengthy
> time
> >> to review the changes and provide feedback. I will also make sure that
> >> everyone on my team also reviews and provides feedback.
> >>
> >> Can we set a deadline of Wednesday the 12th for feedback?
> >>
> >> Thanks again for all your hard work Julian.
> >>
> >> Jacques
> >>
> >> On Wed, Nov 5, 2014 at 3:14 PM, Julian Hyde <ju...@gmail.com>
> wrote:
> >>
> >>> I have completed phases (a) and (b), and I’ve posted the generated
> >>> javadocs to http://www.hydromatic.net/calcite-296/apidocs/.
> >>>
> >>> I’d appreciate reviews.
> >>> Are the package names intuitive? For example, should I rename
> >>> org.apache.calcite.impl to org.apache.calcite.adapters?
> >>> Since most of the classes under org.apache.calcite (Table, Schema etc.)
> >>> form the metadata SPI, should I move them to a new package
> >>> org.apache.calcite.schema?
> >>>
> >>> There’s still time to rename things.
> >>>
> >>> To see the renames, look at the git log:
> >>>
> https://github.com/julianhyde/incubator-calcite/commit/afbe561483c87acf8ab8a1965f48980b09e1207a
> >>> .
> >>>
> >>> Julian
> >>>
> >>> On Nov 5, 2014, at 11:22 AM, andrew <an...@primer.org> wrote:
> >>>
> >>>> Thank you Julian! This will make working with Calcite so much easier,
> >>> especially the changes to enumerable.
> >>>>
> >>>>
> >>>>> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com>
> wrote:
> >>>>>
> >>>>> I’m structuring it as (a) a commit that renames / moves / deletes
> files
> >>> only (no content changes in the files), (b) a commit that fixes up
> class
> >>> names, package names, and imposes the new rule for import ordering. I
> may
> >>> have removed one or two deprecated methods and classes in (b), but not
> many.
> >>>>>
> >>>>> I’ve most finished (b) and will check into my calcite-296 branch
> today.
> >>>>>
> >>>>> Then will come (c) moving the “enumerable” adapter (formerly
> >>> net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java, now
> >>> org.apache.calcite.impl.enumerable) into a new module.
> >>>>>
> >>>>> Julian
> >>>>>
> >>>>>
> >>>>> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <
> >>> sitnikov.vladimir@gmail.com> wrote:
> >>>>>
> >>>>>>> I'm inclined to change names initially. Then step two is any class
> >>> deletes
> >>>>>>> or method sig changes.
> >>>>>>
> >>>>>> I like the idea to perform renames (e.g. renames of packages,
> classes)
> >>>>>> and signature changes (e.g. adding new constructor parameters) in
> >>>>>> different commits.
> >>>>>>
> >>>>>> Anyway, +1 for rolling the renames.
> >>>>>>
> >>>>>> --
> >>>>>> Vladimir
> >>>>>
> >>>>
> >>>
> >>>
> >
>
>
Re: The great renaming
Posted by Julian Hyde <ju...@gmail.com>.
An update.
Release 0.9.2 is almost through the Apache Incubator PMC vote process (fingers crossed!) so if all goes well we should be able to release tonight. Then I'd like to check the changes into master ASAP.
A reminder that today is the deadline for review comments. If if no show-stoppers come up, I'll check in tomorrow (rebasing and squashing what is in https://github.com/julianhyde/incubator-calcite/commit/67c6940b6845c5223ed9870efb58e97c4967aa70).
I'll also produce a document that describes the before:after name mapping.
Julian
> On Nov 6, 2014, at 10:21 AM, Julian Hyde <ju...@hydromatic.net> wrote:
>
> A week for feedback is perfectly reasonable. However, feel free to provide feedback earlier. I think we will go through several iterations before we are ready to call this 1.0. If most people can provide their feedback within a day or so, we can get through those iterations faster.
>
> I already have Andrew’s feedback and will be fixing it in the next day or so.
>
> Julian
>
>
> On Nov 5, 2014, at 9:20 PM, Jacques Nadeau <ja...@apache.org> wrote:
>
>> Given that these are fairly important decisions, I'd request a lengthy time
>> to review the changes and provide feedback. I will also make sure that
>> everyone on my team also reviews and provides feedback.
>>
>> Can we set a deadline of Wednesday the 12th for feedback?
>>
>> Thanks again for all your hard work Julian.
>>
>> Jacques
>>
>> On Wed, Nov 5, 2014 at 3:14 PM, Julian Hyde <ju...@gmail.com> wrote:
>>
>>> I have completed phases (a) and (b), and I’ve posted the generated
>>> javadocs to http://www.hydromatic.net/calcite-296/apidocs/.
>>>
>>> I’d appreciate reviews.
>>> Are the package names intuitive? For example, should I rename
>>> org.apache.calcite.impl to org.apache.calcite.adapters?
>>> Since most of the classes under org.apache.calcite (Table, Schema etc.)
>>> form the metadata SPI, should I move them to a new package
>>> org.apache.calcite.schema?
>>>
>>> There’s still time to rename things.
>>>
>>> To see the renames, look at the git log:
>>> https://github.com/julianhyde/incubator-calcite/commit/afbe561483c87acf8ab8a1965f48980b09e1207a
>>> .
>>>
>>> Julian
>>>
>>> On Nov 5, 2014, at 11:22 AM, andrew <an...@primer.org> wrote:
>>>
>>>> Thank you Julian! This will make working with Calcite so much easier,
>>> especially the changes to enumerable.
>>>>
>>>>
>>>>> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com> wrote:
>>>>>
>>>>> I’m structuring it as (a) a commit that renames / moves / deletes files
>>> only (no content changes in the files), (b) a commit that fixes up class
>>> names, package names, and imposes the new rule for import ordering. I may
>>> have removed one or two deprecated methods and classes in (b), but not many.
>>>>>
>>>>> I’ve most finished (b) and will check into my calcite-296 branch today.
>>>>>
>>>>> Then will come (c) moving the “enumerable” adapter (formerly
>>> net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java, now
>>> org.apache.calcite.impl.enumerable) into a new module.
>>>>>
>>>>> Julian
>>>>>
>>>>>
>>>>> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <
>>> sitnikov.vladimir@gmail.com> wrote:
>>>>>
>>>>>>> I'm inclined to change names initially. Then step two is any class
>>> deletes
>>>>>>> or method sig changes.
>>>>>>
>>>>>> I like the idea to perform renames (e.g. renames of packages, classes)
>>>>>> and signature changes (e.g. adding new constructor parameters) in
>>>>>> different commits.
>>>>>>
>>>>>> Anyway, +1 for rolling the renames.
>>>>>>
>>>>>> --
>>>>>> Vladimir
>>>>>
>>>>
>>>
>>>
>
Re: The great renaming
Posted by Julian Hyde <ju...@hydromatic.net>.
A week for feedback is perfectly reasonable. However, feel free to provide feedback earlier. I think we will go through several iterations before we are ready to call this 1.0. If most people can provide their feedback within a day or so, we can get through those iterations faster.
I already have Andrew’s feedback and will be fixing it in the next day or so.
Julian
On Nov 5, 2014, at 9:20 PM, Jacques Nadeau <ja...@apache.org> wrote:
> Given that these are fairly important decisions, I'd request a lengthy time
> to review the changes and provide feedback. I will also make sure that
> everyone on my team also reviews and provides feedback.
>
> Can we set a deadline of Wednesday the 12th for feedback?
>
> Thanks again for all your hard work Julian.
>
> Jacques
>
> On Wed, Nov 5, 2014 at 3:14 PM, Julian Hyde <ju...@gmail.com> wrote:
>
>> I have completed phases (a) and (b), and I’ve posted the generated
>> javadocs to http://www.hydromatic.net/calcite-296/apidocs/.
>>
>> I’d appreciate reviews.
>> Are the package names intuitive? For example, should I rename
>> org.apache.calcite.impl to org.apache.calcite.adapters?
>> Since most of the classes under org.apache.calcite (Table, Schema etc.)
>> form the metadata SPI, should I move them to a new package
>> org.apache.calcite.schema?
>>
>> There’s still time to rename things.
>>
>> To see the renames, look at the git log:
>> https://github.com/julianhyde/incubator-calcite/commit/afbe561483c87acf8ab8a1965f48980b09e1207a
>> .
>>
>> Julian
>>
>> On Nov 5, 2014, at 11:22 AM, andrew <an...@primer.org> wrote:
>>
>>> Thank you Julian! This will make working with Calcite so much easier,
>> especially the changes to enumerable.
>>>
>>>
>>>> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com> wrote:
>>>>
>>>> I’m structuring it as (a) a commit that renames / moves / deletes files
>> only (no content changes in the files), (b) a commit that fixes up class
>> names, package names, and imposes the new rule for import ordering. I may
>> have removed one or two deprecated methods and classes in (b), but not many.
>>>>
>>>> I’ve most finished (b) and will check into my calcite-296 branch today.
>>>>
>>>> Then will come (c) moving the “enumerable” adapter (formerly
>> net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java, now
>> org.apache.calcite.impl.enumerable) into a new module.
>>>>
>>>> Julian
>>>>
>>>>
>>>> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <
>> sitnikov.vladimir@gmail.com> wrote:
>>>>
>>>>>> I'm inclined to change names initially. Then step two is any class
>> deletes
>>>>>> or method sig changes.
>>>>>
>>>>> I like the idea to perform renames (e.g. renames of packages, classes)
>>>>> and signature changes (e.g. adding new constructor parameters) in
>>>>> different commits.
>>>>>
>>>>> Anyway, +1 for rolling the renames.
>>>>>
>>>>> --
>>>>> Vladimir
>>>>
>>>
>>
>>
Re: The great renaming
Posted by Jacques Nadeau <ja...@apache.org>.
Given that these are fairly important decisions, I'd request a lengthy time
to review the changes and provide feedback. I will also make sure that
everyone on my team also reviews and provides feedback.
Can we set a deadline of Wednesday the 12th for feedback?
Thanks again for all your hard work Julian.
Jacques
On Wed, Nov 5, 2014 at 3:14 PM, Julian Hyde <ju...@gmail.com> wrote:
> I have completed phases (a) and (b), and I’ve posted the generated
> javadocs to http://www.hydromatic.net/calcite-296/apidocs/.
>
> I’d appreciate reviews.
> Are the package names intuitive? For example, should I rename
> org.apache.calcite.impl to org.apache.calcite.adapters?
> Since most of the classes under org.apache.calcite (Table, Schema etc.)
> form the metadata SPI, should I move them to a new package
> org.apache.calcite.schema?
>
> There’s still time to rename things.
>
> To see the renames, look at the git log:
> https://github.com/julianhyde/incubator-calcite/commit/afbe561483c87acf8ab8a1965f48980b09e1207a
> .
>
> Julian
>
> On Nov 5, 2014, at 11:22 AM, andrew <an...@primer.org> wrote:
>
> > Thank you Julian! This will make working with Calcite so much easier,
> especially the changes to enumerable.
> >
> >
> >> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com> wrote:
> >>
> >> I’m structuring it as (a) a commit that renames / moves / deletes files
> only (no content changes in the files), (b) a commit that fixes up class
> names, package names, and imposes the new rule for import ordering. I may
> have removed one or two deprecated methods and classes in (b), but not many.
> >>
> >> I’ve most finished (b) and will check into my calcite-296 branch today.
> >>
> >> Then will come (c) moving the “enumerable” adapter (formerly
> net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java, now
> org.apache.calcite.impl.enumerable) into a new module.
> >>
> >> Julian
> >>
> >>
> >> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
> >>
> >>>> I'm inclined to change names initially. Then step two is any class
> deletes
> >>>> or method sig changes.
> >>>
> >>> I like the idea to perform renames (e.g. renames of packages, classes)
> >>> and signature changes (e.g. adding new constructor parameters) in
> >>> different commits.
> >>>
> >>> Anyway, +1 for rolling the renames.
> >>>
> >>> --
> >>> Vladimir
> >>
> >
>
>
Re: The great renaming
Posted by Julian Hyde <ju...@gmail.com>.
I have completed phases (a) and (b), and I’ve posted the generated javadocs to http://www.hydromatic.net/calcite-296/apidocs/.
I’d appreciate reviews.
Are the package names intuitive? For example, should I rename org.apache.calcite.impl to org.apache.calcite.adapters?
Since most of the classes under org.apache.calcite (Table, Schema etc.) form the metadata SPI, should I move them to a new package org.apache.calcite.schema?
There’s still time to rename things.
To see the renames, look at the git log: https://github.com/julianhyde/incubator-calcite/commit/afbe561483c87acf8ab8a1965f48980b09e1207a.
Julian
On Nov 5, 2014, at 11:22 AM, andrew <an...@primer.org> wrote:
> Thank you Julian! This will make working with Calcite so much easier, especially the changes to enumerable.
>
>
>> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com> wrote:
>>
>> I’m structuring it as (a) a commit that renames / moves / deletes files only (no content changes in the files), (b) a commit that fixes up class names, package names, and imposes the new rule for import ordering. I may have removed one or two deprecated methods and classes in (b), but not many.
>>
>> I’ve most finished (b) and will check into my calcite-296 branch today.
>>
>> Then will come (c) moving the “enumerable” adapter (formerly net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java, now org.apache.calcite.impl.enumerable) into a new module.
>>
>> Julian
>>
>>
>> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>>
>>>> I'm inclined to change names initially. Then step two is any class deletes
>>>> or method sig changes.
>>>
>>> I like the idea to perform renames (e.g. renames of packages, classes)
>>> and signature changes (e.g. adding new constructor parameters) in
>>> different commits.
>>>
>>> Anyway, +1 for rolling the renames.
>>>
>>> --
>>> Vladimir
>>
>
Re: The great renaming
Posted by andrew <an...@primer.org>.
Thank you Julian! This will make working with Calcite so much easier, especially the changes to enumerable.
> On Nov 5, 2014, at 10:35 AM, Julian Hyde <ju...@gmail.com> wrote:
>
> I’m structuring it as (a) a commit that renames / moves / deletes files only (no content changes in the files), (b) a commit that fixes up class names, package names, and imposes the new rule for import ordering. I may have removed one or two deprecated methods and classes in (b), but not many.
>
> I’ve most finished (b) and will check into my calcite-296 branch today.
>
> Then will come (c) moving the “enumerable” adapter (formerly net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java, now org.apache.calcite.impl.enumerable) into a new module.
>
> Julian
>
>
> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
>>> I'm inclined to change names initially. Then step two is any class deletes
>>> or method sig changes.
>>
>> I like the idea to perform renames (e.g. renames of packages, classes)
>> and signature changes (e.g. adding new constructor parameters) in
>> different commits.
>>
>> Anyway, +1 for rolling the renames.
>>
>> --
>> Vladimir
>
Re: The great renaming
Posted by Jacques Nadeau <ja...@apache.org>.
+1
On Wed, Nov 5, 2014 at 10:35 AM, Julian Hyde <ju...@gmail.com> wrote:
> I’m structuring it as (a) a commit that renames / moves / deletes files
> only (no content changes in the files), (b) a commit that fixes up class
> names, package names, and imposes the new rule for import ordering. I may
> have removed one or two deprecated methods and classes in (b), but not many.
>
> I’ve most finished (b) and will check into my calcite-296 branch today.
>
> Then will come (c) moving the “enumerable” adapter (formerly
> net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java, now
> org.apache.calcite.impl.enumerable) into a new module.
>
> Julian
>
>
> On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <si...@gmail.com>
> wrote:
>
> >> I'm inclined to change names initially. Then step two is any class
> deletes
> >> or method sig changes.
> >
> > I like the idea to perform renames (e.g. renames of packages, classes)
> > and signature changes (e.g. adding new constructor parameters) in
> > different commits.
> >
> > Anyway, +1 for rolling the renames.
> >
> > --
> > Vladimir
>
>
Re: The great renaming
Posted by Julian Hyde <ju...@gmail.com>.
I’m structuring it as (a) a commit that renames / moves / deletes files only (no content changes in the files), (b) a commit that fixes up class names, package names, and imposes the new rule for import ordering. I may have removed one or two deprecated methods and classes in (b), but not many.
I’ve most finished (b) and will check into my calcite-296 branch today.
Then will come (c) moving the “enumerable” adapter (formerly net.hydromatic.optiq.impl.java and net.hydromatic.optiq.rules.java, now org.apache.calcite.impl.enumerable) into a new module.
Julian
On Nov 5, 2014, at 3:54 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>> I'm inclined to change names initially. Then step two is any class deletes
>> or method sig changes.
>
> I like the idea to perform renames (e.g. renames of packages, classes)
> and signature changes (e.g. adding new constructor parameters) in
> different commits.
>
> Anyway, +1 for rolling the renames.
>
> --
> Vladimir
Re: The great renaming
Posted by Vladimir Sitnikov <si...@gmail.com>.
>I'm inclined to change names initially. Then step two is any class deletes
>or method sig changes.
I like the idea to perform renames (e.g. renames of packages, classes)
and signature changes (e.g. adding new constructor parameters) in
different commits.
Anyway, +1 for rolling the renames.
--
Vladimir
RE: The great renaming
Posted by "Li, Yang" <ya...@ebay.com>.
+1
-----Original Message-----
From: Julian Hyde [mailto:jhyde@apache.org]
Sent: 2014年11月5日 12:49
To: dev@calcite.incubator.apache.org
Subject: The great renaming
I have a few thoughts on Calcite's development/release schedule for the next month or so.
First, you saw the announcement of 0.9.1-incubating. That release was from code that we froze almost a month ago, but it took a while to go through the two votes, and then a while to get the artifacts posted to public sites.
Also, we now have a web site. Thanks to Sree for getting that ball rolling. If you got to http://calcite.incubator.apache.org/ and click on Releases > 0.9.1-incubating, you should be able to download the artifacts.
I am working on https://issues.apache.org/jira/browse/CALCITE-296 and https://issues.apache.org/jira/browse/CALCITE-419, aka the great renaming. Every package name is changing, and quite a few class names as well (for instance, FilterRel moves from org.eigenbase.rel to org.apache.calcite.rel.logical and is renamed to LogicalFilter, while its base class FilterRelBase moves to org.apache.calcite.rel.core and is renamed to Filter). We are also going to remove some deprecated methods and classes. I think our users will have a problem if we change a lot of names and significantly change functionality.
So, I propose to do a quick release 0.9.2-incubating based on what is currently in master, merge the renamed packages, and then make a release of the renamed code without adding a lot of extra functionality. Because of the renames, I am tempted to call that release 1.0 beta.
I think we can make a release candidate for 0.9.2 in the next day or two, then move to a vote.
The web site could also use some work, for example javadoc, and adding the content currently in the HOWTO, HISTORY and README files. That could be rolled out with 0.9.2, if someone can get to it in the next week or so.
If you're working on patches to Calcite code, I won't be inclined to accept them into 0.9.2 unless they fix critical bugs. And the first change integrated after 0.9.2 will be the package re-org. For any other changes, be prepared to integrate the patch (i.e. manually
rebase) into the renamed package structure.
Thoughts on this plan? If it sounds awesome, I'd appreciate some +1s so I know you're out there.
Julian
Re: The great renaming
Posted by Yash Sharma <ya...@gmail.com>.
+1. Sounds awesome to me.
On Wed, Nov 5, 2014 at 10:20 AM, James Taylor <ja...@apache.org>
wrote:
> +1
>
> On Tue, Nov 4, 2014 at 8:48 PM, Julian Hyde <jh...@apache.org> wrote:
> > I have a few thoughts on Calcite's development/release schedule for
> > the next month or so.
> >
> > First, you saw the announcement of 0.9.1-incubating. That release was
> > from code that we froze almost a month ago, but it took a while to go
> > through the two votes, and then a while to get the artifacts posted to
> > public sites.
> >
> > Also, we now have a web site. Thanks to Sree for getting that ball
> > rolling. If you got to http://calcite.incubator.apache.org/ and click
> > on Releases > 0.9.1-incubating, you should be able to download the
> > artifacts.
> >
> > I am working on https://issues.apache.org/jira/browse/CALCITE-296 and
> > https://issues.apache.org/jira/browse/CALCITE-419, aka the great
> > renaming. Every package name is changing, and quite a few class names
> > as well (for instance, FilterRel moves from org.eigenbase.rel to
> > org.apache.calcite.rel.logical and is renamed to LogicalFilter, while
> > its base class FilterRelBase moves to org.apache.calcite.rel.core and
> > is renamed to Filter). We are also going to remove some deprecated
> > methods and classes. I think our users will have a problem if we
> > change a lot of names and significantly change functionality.
> >
> > So, I propose to do a quick release 0.9.2-incubating based on what is
> > currently in master, merge the renamed packages, and then make a
> > release of the renamed code without adding a lot of extra
> > functionality. Because of the renames, I am tempted to call that
> > release 1.0 beta.
> >
> > I think we can make a release candidate for 0.9.2 in the next day or
> > two, then move to a vote.
> >
> > The web site could also use some work, for example javadoc, and adding
> > the content currently in the HOWTO, HISTORY and README files. That
> > could be rolled out with 0.9.2, if someone can get to it in the next
> > week or so.
> >
> > If you're working on patches to Calcite code, I won't be inclined to
> > accept them into 0.9.2 unless they fix critical bugs. And the first
> > change integrated after 0.9.2 will be the package re-org. For any
> > other changes, be prepared to integrate the patch (i.e. manually
> > rebase) into the renamed package structure.
> >
> > Thoughts on this plan? If it sounds awesome, I'd appreciate some +1s
> > so I know you're out there.
> >
> > Julian
>
Re: The great renaming
Posted by James Taylor <ja...@apache.org>.
+1
On Tue, Nov 4, 2014 at 8:48 PM, Julian Hyde <jh...@apache.org> wrote:
> I have a few thoughts on Calcite's development/release schedule for
> the next month or so.
>
> First, you saw the announcement of 0.9.1-incubating. That release was
> from code that we froze almost a month ago, but it took a while to go
> through the two votes, and then a while to get the artifacts posted to
> public sites.
>
> Also, we now have a web site. Thanks to Sree for getting that ball
> rolling. If you got to http://calcite.incubator.apache.org/ and click
> on Releases > 0.9.1-incubating, you should be able to download the
> artifacts.
>
> I am working on https://issues.apache.org/jira/browse/CALCITE-296 and
> https://issues.apache.org/jira/browse/CALCITE-419, aka the great
> renaming. Every package name is changing, and quite a few class names
> as well (for instance, FilterRel moves from org.eigenbase.rel to
> org.apache.calcite.rel.logical and is renamed to LogicalFilter, while
> its base class FilterRelBase moves to org.apache.calcite.rel.core and
> is renamed to Filter). We are also going to remove some deprecated
> methods and classes. I think our users will have a problem if we
> change a lot of names and significantly change functionality.
>
> So, I propose to do a quick release 0.9.2-incubating based on what is
> currently in master, merge the renamed packages, and then make a
> release of the renamed code without adding a lot of extra
> functionality. Because of the renames, I am tempted to call that
> release 1.0 beta.
>
> I think we can make a release candidate for 0.9.2 in the next day or
> two, then move to a vote.
>
> The web site could also use some work, for example javadoc, and adding
> the content currently in the HOWTO, HISTORY and README files. That
> could be rolled out with 0.9.2, if someone can get to it in the next
> week or so.
>
> If you're working on patches to Calcite code, I won't be inclined to
> accept them into 0.9.2 unless they fix critical bugs. And the first
> change integrated after 0.9.2 will be the package re-org. For any
> other changes, be prepared to integrate the patch (i.e. manually
> rebase) into the renamed package structure.
>
> Thoughts on this plan? If it sounds awesome, I'd appreciate some +1s
> so I know you're out there.
>
> Julian
Re: The great renaming
Posted by "Han, Luke" <lu...@ebay.com>.
+1
Best Regards!
------------------------
Luke Han | 韩卿
Phone: 86-21-28913802 | Mobile: 86-18616265832
Mail: lukhan@ebay.com | Skype: luke.hanqing
On 11/5/14, 12:48 PM, "Julian Hyde" <jh...@apache.org> wrote:
>I have a few thoughts on Calcite's development/release schedule for
>the next month or so.
>
>First, you saw the announcement of 0.9.1-incubating. That release was
>from code that we froze almost a month ago, but it took a while to go
>through the two votes, and then a while to get the artifacts posted to
>public sites.
>
>Also, we now have a web site. Thanks to Sree for getting that ball
>rolling. If you got to http://calcite.incubator.apache.org/ and click
>on Releases > 0.9.1-incubating, you should be able to download the
>artifacts.
>
>I am working on https://issues.apache.org/jira/browse/CALCITE-296 and
>https://issues.apache.org/jira/browse/CALCITE-419, aka the great
>renaming. Every package name is changing, and quite a few class names
>as well (for instance, FilterRel moves from org.eigenbase.rel to
>org.apache.calcite.rel.logical and is renamed to LogicalFilter, while
>its base class FilterRelBase moves to org.apache.calcite.rel.core and
>is renamed to Filter). We are also going to remove some deprecated
>methods and classes. I think our users will have a problem if we
>change a lot of names and significantly change functionality.
>
>So, I propose to do a quick release 0.9.2-incubating based on what is
>currently in master, merge the renamed packages, and then make a
>release of the renamed code without adding a lot of extra
>functionality. Because of the renames, I am tempted to call that
>release 1.0 beta.
>
>I think we can make a release candidate for 0.9.2 in the next day or
>two, then move to a vote.
>
>The web site could also use some work, for example javadoc, and adding
>the content currently in the HOWTO, HISTORY and README files. That
>could be rolled out with 0.9.2, if someone can get to it in the next
>week or so.
>
>If you're working on patches to Calcite code, I won't be inclined to
>accept them into 0.9.2 unless they fix critical bugs. And the first
>change integrated after 0.9.2 will be the package re-org. For any
>other changes, be prepared to integrate the patch (i.e. manually
>rebase) into the renamed package structure.
>
>Thoughts on this plan? If it sounds awesome, I'd appreciate some +1s
>so I know you're out there.
>
>Julian
Re: The great renaming
Posted by Steven Noels <st...@apache.org>.
On Wed, Nov 5, 2014, at 05:48 AM, Julian Hyde wrote:
>
> Thoughts on this plan? If it sounds awesome, I'd appreciate some +1s
> so I know you're out there.
+1
Steven.
Re: The great renaming
Posted by Jacques Nadeau <ja...@apache.org>.
I'm inclined to change names initially. Then step two is any class deletes
or method sig changes.
We also talked about module splitting at the hackathon. I haven't made any
progress but want to know where you think that fits.
On Nov 4, 2014 8:49 PM, "Julian Hyde" <jh...@apache.org> wrote:
> I have a few thoughts on Calcite's development/release schedule for
> the next month or so.
>
> First, you saw the announcement of 0.9.1-incubating. That release was
> from code that we froze almost a month ago, but it took a while to go
> through the two votes, and then a while to get the artifacts posted to
> public sites.
>
> Also, we now have a web site. Thanks to Sree for getting that ball
> rolling. If you got to http://calcite.incubator.apache.org/ and click
> on Releases > 0.9.1-incubating, you should be able to download the
> artifacts.
>
> I am working on https://issues.apache.org/jira/browse/CALCITE-296 and
> https://issues.apache.org/jira/browse/CALCITE-419, aka the great
> renaming. Every package name is changing, and quite a few class names
> as well (for instance, FilterRel moves from org.eigenbase.rel to
> org.apache.calcite.rel.logical and is renamed to LogicalFilter, while
> its base class FilterRelBase moves to org.apache.calcite.rel.core and
> is renamed to Filter). We are also going to remove some deprecated
> methods and classes. I think our users will have a problem if we
> change a lot of names and significantly change functionality.
>
> So, I propose to do a quick release 0.9.2-incubating based on what is
> currently in master, merge the renamed packages, and then make a
> release of the renamed code without adding a lot of extra
> functionality. Because of the renames, I am tempted to call that
> release 1.0 beta.
>
> I think we can make a release candidate for 0.9.2 in the next day or
> two, then move to a vote.
>
> The web site could also use some work, for example javadoc, and adding
> the content currently in the HOWTO, HISTORY and README files. That
> could be rolled out with 0.9.2, if someone can get to it in the next
> week or so.
>
> If you're working on patches to Calcite code, I won't be inclined to
> accept them into 0.9.2 unless they fix critical bugs. And the first
> change integrated after 0.9.2 will be the package re-org. For any
> other changes, be prepared to integrate the patch (i.e. manually
> rebase) into the renamed package structure.
>
> Thoughts on this plan? If it sounds awesome, I'd appreciate some +1s
> so I know you're out there.
>
> Julian
>