[ 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
