Hi Noel,
It will probably be more complex than just patching the readFromAlias >> method, if derived column lists should be implemented thoroughly. >> > Agreed. Stick to the simple case first, and don't forget to add unit > tests, and make sure the existing tests pass. I've been going through the sources and I can see one major design issue that is bothering me a little bit. Parsing [[AS] <correlation> [(<derived-column-list>)]] seems to be rather simple, as the parser is implemented in a straight forward way. Once parsed, I think that the central place where a <derived column list> should be applied to is org.h2.table.TableFilter.getColumns(). Or, more specifically org.h2.table.ColumnResolver.getColumns(). This method should then return "views" to the underlying table's real columns, implementing column renaming abstraction. However, TableFilter exposes its underlying Table and thus the underlying Column instances, which are referenced from methods like Aggregate.getColumnIndex(), Select.expandColumnList(), Parser.readJoin(), Update.update(), etc. I think it is unwise to implement this new feature without first cleaning up this leaking of org.h2.table.Table into TableFilter's various call-sites. What do you think about these findings? I'll give it a shot, though. Is there a formal grammar specification >> (apart from the informal HTML documentation) somewhere in the H2 >> repository, which I should adapt? >> >> Yes, update the > src/docsrc/help/help.csv > file. Thanks for the link -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
