Mike Matrigali wrote: > 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 sounds good, balancing what is good for users and developers working with JIRA's limitations. So, I would suggest: SQL SQL-parser SQL-optimizer SQL-compiler SQL-datatype SQL-execute or SQL-executor (First one matches 'execute' package name) Satheesh > > 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 >>> >>> >> >> >> >> > > >
