I agree that sub-component would be better, but not available.
I don't expect most users to be able to set the internal component
so I think it is fine to leave SQL. The subcomponents would be a
way for someone who understands the issue a little more to classify
it. SQL-parser, SQL-optimizer, SQL-compiler, SQL-engine seem like
a good start.
This way if someone is looking to do work on the optimizer, they
can quickly scan to see work available in the area.
Satheesh Bandaram wrote:
Andrew McIntyre wrote:
It felt most unsatisfying assigning a lot of issues to SQL, which
really
are internal "sql execution" issues. And if we had the categories a
lot
I could have assigned to optimizer, parser, execution.
It's easy to add and remove components. If you have specific
component names to use, let me know, or I can just go with SQL
Parser, Optimizer, Compile/Execute (just 'Execution' would be a
little confusing I think).
I am not sure if many users of Derby can identify which component of SQL
the problem may be. It would have been great to have sub-components,
with SQL component having Mike's suggested sub-components. May be we
could call them SQL - parser, SQL - optimizer, SQL - compiler and SQL -
engine, but the distinction may not be clear to end users.
Satheesh
andrew
