Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 1.8.4, 2.0-beta-2
-
Fix Version/s: 2.0-beta-3, 1.8.7
-
Component/s: SQL processing
-
Labels:None
-
Number of attachments :
Description
To customize the behavior of groovy.sql.Sql we override "protected groovy.sql.Sql.createQueryCommand(String)". Next, we attempt to implement the inner class groovy.sql.Sql.AbstractQueryCommand. Its only constructor "AbstractQueryCommand(String sql)" is package-protected. therefore subclassing is impossible unless we put our code into package "groovy.sql" which is against best practice.
As a side note, AbstractQueryCommand is non-static, therefore requires an instance of groovy.sql.Sql for instantiation.
I guess one would only want to subclass AbstractQueryCommand after subclassing Sql first, so this won't be an issue. Still, an instance of Sql could be provided on the constructor explicitly and let the inner class be static.
The constructor for AbstractQueryCommand now has protected visibility allowing for extension in combination with extending groovy.sql.Sql.
It would also be possible to make AbstractQueryCommand static - or indeed a top-level class - but that seems like a lower priority change to me and we currently don't have a strong example/use case/justification driving that change. I am at this stage inclined to close this issue and leave such changes to be done if/when other refactoring takes place in the future. Do you agree or instead have further use cases/examples to be considered?