You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <de...@db.apache.org> on 2005/11/02 18:21:56 UTC
[jira] Created: (DERBY-673) Get rid of the NodeFactory
Get rid of the NodeFactory
--------------------------
Key: DERBY-673
URL: http://issues.apache.org/jira/browse/DERBY-673
Project: Derby
Type: New Feature
Reporter: Rick Hillegas
This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this.
The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Voitng on Jira issues
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
TomohitoNakayama wrote:
> Hello.
>
> I was interested in VOTE link at JIRA issue too , however, I'm not sure
> what is JIRA voting feature exactly ...
>
> I don't know whether it matches our requirement for voting .
> For example ...
> * Sometimes we vote not only +1 , but also vote +0.5,+0,-0,-0.5 , as
> expression of subtle opinion.
> * Sometimes we have multiple voting on single issue .
>
> // I suspect that vote in JIRA is different from our familiar vote in
> mailing list , though they use same word "vote" .
> // Vote in JIRA may be just voting whether accept the issue or neglect
> it . Are there someone who have used vote feature in JIRA already ?
If I remember right, Kathey Marsden has been using Jira votes to see
which features most interest users.
However, it's a vote/unvote toggle, and it doesn't reveal who cast the
vote, which is important when binding votes by committers need to be
considered.
So, the Jira vote is nice for determining interest. But when a formal
vote is required, that vote needs to be carried out on the derby-dev
mail list.
-jean
>
> Best regards.
>
> Bernt M. Johnsen wrote:
>
>> Sorry for the norwegian. Meant for Dag directly.
>>
>> But what does the community think: Shouldn't voting on Jira issues
>> use the Jira voting feature?
>>
>>
>>
>>
>>>>>>>>>>>>>> Bernt M. Johnsen wrote (2005-11-03 09:48:13):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Dag H. Wanvik wrote (2005-11-03 03:05:01):
>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> "Rick" == Rick Hillegas (JIRA) <de...@db.apache.org> wrote:
>>>>>>>>>
>>>>
>>>> Rick> The NodeFactory turned into a big, sprawling piece of code. At
>>>> Rick> some point this code was slimmed down by telescoping all of its
>>>> Rick> factory methods into a couple unwieldly, weakly-typed overloads
>>>> Rick> backed by cumbersome logic in the actual node constructors. I
>>>> Rick> would like to reintroduce strongly typed node constructors which
>>>> Rick> the parser can call directly. This will make node generation
>>>> Rick> easier to read and less brittle and it will get rid of the now
>>>> Rick> useless NodeFactory class.
>>>>
>>>> +1
>>>>
>>>
>>> Bruk vote i JIRA...... det er det som egentlig er mekanismen.
>>>
>>>
>>>> Dag
>>>>
>>>
>>> --
>>> Bernt Marius Johnsen, Database Technology Group, Sun Microsystems,
>>> Trondheim, Norway
>>>
>>
>>
>>
>>
>>
>>
>
Re: Voitng on Jira issues
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I was interested in VOTE link at JIRA issue too , however, I'm not sure
what is JIRA voting feature exactly ...
I don't know whether it matches our requirement for voting .
For example ...
* Sometimes we vote not only +1 , but also vote +0.5,+0,-0,-0.5 , as
expression of subtle opinion.
* Sometimes we have multiple voting on single issue .
// I suspect that vote in JIRA is different from our familiar vote in
mailing list , though they use same word "vote" .
// Vote in JIRA may be just voting whether accept the issue or neglect
it . Are there someone who have used vote feature in JIRA already ?
Best regards.
Bernt M. Johnsen wrote:
>Sorry for the norwegian. Meant for Dag directly.
>
>But what does the community think: Shouldn't voting on Jira issues
>use the Jira voting feature?
>
>
>
>
>>>>>>>>>>>>>Bernt M. Johnsen wrote (2005-11-03 09:48:13):
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>Dag H. Wanvik wrote (2005-11-03 03:05:01):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>"Rick" == Rick Hillegas (JIRA) <de...@db.apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>Rick> The NodeFactory turned into a big, sprawling piece of code. At
>>>Rick> some point this code was slimmed down by telescoping all of its
>>>Rick> factory methods into a couple unwieldly, weakly-typed overloads
>>>Rick> backed by cumbersome logic in the actual node constructors. I
>>>Rick> would like to reintroduce strongly typed node constructors which
>>>Rick> the parser can call directly. This will make node generation
>>>Rick> easier to read and less brittle and it will get rid of the now
>>>Rick> useless NodeFactory class.
>>>
>>>+1
>>>
>>>
>>Bruk vote i JIRA...... det er det som egentlig er mekanismen.
>>
>>
>>>Dag
>>>
>>>
>>--
>>Bernt Marius Johnsen, Database Technology Group,
>>Sun Microsystems, Trondheim, Norway
>>
>>
>
>
>
>
>
--
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
Re: Voitng on Jira issues
Posted by Francois Orsini <fr...@gmail.com>.
Well, according to what I've heard before - all votes should be recorded via
email on the Apache mailing list (w/ specific formatted subject, etc) - now
I wonder if JIRA sends an email notification to the list if someone makes a
vote via the JIRA voting feature?
--francois
Voitng on Jira issues
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
Sorry for the norwegian. Meant for Dag directly.
But what does the community think: Shouldn't voting on Jira issues
use the Jira voting feature?
>>>>>>>>>>>> Bernt M. Johnsen wrote (2005-11-03 09:48:13):
> >>>>>>>>>>>> Dag H. Wanvik wrote (2005-11-03 03:05:01):
> >
> > >>>>> "Rick" == Rick Hillegas (JIRA) <de...@db.apache.org> wrote:
> >
> > Rick> The NodeFactory turned into a big, sprawling piece of code. At
> > Rick> some point this code was slimmed down by telescoping all of its
> > Rick> factory methods into a couple unwieldly, weakly-typed overloads
> > Rick> backed by cumbersome logic in the actual node constructors. I
> > Rick> would like to reintroduce strongly typed node constructors which
> > Rick> the parser can call directly. This will make node generation
> > Rick> easier to read and less brittle and it will get rid of the now
> > Rick> useless NodeFactory class.
> >
> > +1
>
> Bruk vote i JIRA...... det er det som egentlig er mekanismen.
> >
> > Dag
>
> --
> Bernt Marius Johnsen, Database Technology Group,
> Sun Microsystems, Trondheim, Norway
--
Bernt Marius Johnsen, Database Technology Group,
Sun Microsystems, Trondheim, Norway
Re: [jira] Created: (DERBY-673) Get rid of the NodeFactory
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Dag H. Wanvik wrote (2005-11-03 03:05:01):
>
> >>>>> "Rick" == Rick Hillegas (JIRA) <de...@db.apache.org> wrote:
>
> Rick> The NodeFactory turned into a big, sprawling piece of code. At
> Rick> some point this code was slimmed down by telescoping all of its
> Rick> factory methods into a couple unwieldly, weakly-typed overloads
> Rick> backed by cumbersome logic in the actual node constructors. I
> Rick> would like to reintroduce strongly typed node constructors which
> Rick> the parser can call directly. This will make node generation
> Rick> easier to read and less brittle and it will get rid of the now
> Rick> useless NodeFactory class.
>
> +1
Bruk vote i JIRA...... det er det som egentlig er mekanismen.
>
> Dag
--
Bernt Marius Johnsen, Database Technology Group,
Sun Microsystems, Trondheim, Norway
Re: [jira] Created: (DERBY-673) Get rid of the NodeFactory
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
>>>>> "Rick" == Rick Hillegas (JIRA) <de...@db.apache.org> wrote:
Rick> The NodeFactory turned into a big, sprawling piece of code. At
Rick> some point this code was slimmed down by telescoping all of its
Rick> factory methods into a couple unwieldly, weakly-typed overloads
Rick> backed by cumbersome logic in the actual node constructors. I
Rick> would like to reintroduce strongly typed node constructors which
Rick> the parser can call directly. This will make node generation
Rick> easier to read and less brittle and it will get rid of the now
Rick> useless NodeFactory class.
+1
Dag
[jira] Commented: (DERBY-673) Get rid of the NodeFactory
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-673?page=comments#action_12358707 ]
Rick Hillegas commented on DERBY-673:
-------------------------------------
TableName doesn't have a useful optimize() or generate() method but it does have a bind() method. It looks like a reasonable AST node (that is, QueryTreeNode) to me.
> Get rid of the NodeFactory
> --------------------------
>
> Key: DERBY-673
> URL: http://issues.apache.org/jira/browse/DERBY-673
> Project: Derby
> Type: New Feature
> Reporter: Rick Hillegas
>
> This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this.
> The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-673) Get rid of the NodeFactory
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-673?page=comments#action_12358697 ]
Daniel John Debrunner commented on DERBY-673:
---------------------------------------------
Would this change allow some rationalization of the type hierachy for nodes? Every "node" is a sub-class of QueryTreeNode, but it seems to me that several nodes are forced into the hierachy through the use of the NodeFactory. Any "node" that is really a data element would seem to fall into this. E.g. TableName, TableElementNode and its sub-classes. It's possible those nodes do not need to be sub-classes of QueryTreeNode.
> Get rid of the NodeFactory
> --------------------------
>
> Key: DERBY-673
> URL: http://issues.apache.org/jira/browse/DERBY-673
> Project: Derby
> Type: New Feature
> Reporter: Rick Hillegas
>
> This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this.
> The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-673) Get rid of the NodeFactory
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-673?page=comments#action_12358704 ]
Daniel John Debrunner commented on DERBY-673:
---------------------------------------------
The rational is that some current nodes are not really QueryTreeNodes, but common data elements for real nodes. TableName is an example, which actually represents any two part name (e.g. view, table, function, procedure etc.). Some of the list nodes just contain lists of other nodes, it's not clear to me that all these correctly are QueryTreeNodes.
> Get rid of the NodeFactory
> --------------------------
>
> Key: DERBY-673
> URL: http://issues.apache.org/jira/browse/DERBY-673
> Project: Derby
> Type: New Feature
> Reporter: Rick Hillegas
>
> This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this.
> The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-673) Get rid of the NodeFactory
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-673?page=comments#action_12358738 ]
Daniel John Debrunner commented on DERBY-673:
---------------------------------------------
Maybe, but the bind() method doesn't actually bind the node, it just fetches the schema descriptor, which is already handled by other methods on QueryTreeNode. You could implement the functionality of the TableName in query trees, a two part name, without extending QueryTreeNode. Possibly it is never used as a QueryTreeNode and never uses any methods of its parent class.
> Get rid of the NodeFactory
> --------------------------
>
> Key: DERBY-673
> URL: http://issues.apache.org/jira/browse/DERBY-673
> Project: Derby
> Type: New Feature
> Reporter: Rick Hillegas
>
> This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this.
> The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-673) Get rid of the NodeFactory
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-673?page=all ]
Mike Matrigali updated DERBY-673:
---------------------------------
Component: SQL
> Get rid of the NodeFactory
> --------------------------
>
> Key: DERBY-673
> URL: http://issues.apache.org/jira/browse/DERBY-673
> Project: Derby
> Type: New Feature
> Components: SQL
> Reporter: Rick Hillegas
>
> This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this.
> The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-673) Get rid of the NodeFactory
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-673?page=comments#action_12358703 ]
Rick Hillegas commented on DERBY-673:
-------------------------------------
This change should not preclude and I expect it would facilitate reorganizations of the type hierarchy for nodes in the abstract syntax tree. Having said that, I don't think I understand the motivation for making some nodes not descend from QueryTreeNode. QueryTreeNode is supposed to be the ancestor of all abstract syntax tree nodes. This is a useful abstraction because it regularizes compiler code. It removes a lot of special case logic from the handling of the compilation steps defined by QueryTreeNode: bind(), optimize(), and generate(). In addition, it forces an engineer, when adding a new AST node, to account for these steps. I can see some methods in QueryTreeNode which probably belong in its descendants. However, I think QueryTreeNode basically makes a lot of sense and the code would be a lot uglier without this abstraction.
> Get rid of the NodeFactory
> --------------------------
>
> Key: DERBY-673
> URL: http://issues.apache.org/jira/browse/DERBY-673
> Project: Derby
> Type: New Feature
> Reporter: Rick Hillegas
>
> This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this.
> The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira