Groovy team,

 

It is my understanding (which can always be improved!) that Groovy SQL supports 
about 3 “families” of interaction methods – execute() and its variants, rows() 
and eachRow() for submitting SQL statements and processing any results 
generated.

 

Each of them has a variety of signatures and they are for the most part really 
“groovy” and a pleasure to work with.  I really like Groovy and don’t 
understand why it hasn’t taken the world by storm given its super compatibility 
with Java.  😊

 

However, I’ve run across one area that I feel like could benefit from a 
change/enhancement in the Groovy Sql package.  The execute() methods accept a 
closure to process the results that come back from the database/driver and that 
closure accepts two arguments – the first argument specifies whether or not the 
result set has any results and then the second argument processes any results.  
It is that first argument that does not seem to be consistently available in 
the other methods.  For example, if you were to use the rows() method and the 
SQL statement was say in INSERT statement then you’ll get an exception stating 
that the request does not produce a resultSet and there does not appear to be 
any way to work around it.  

 

Of course I could switch from the rows() method to the execute() method but 
then I (appear) to lose the metadata results (column names, types, etc).  

 

My situation is that I do not know in advance what SQL statements are going to 
be processed, they come from user input.  And I need the metadata information – 
for those statements that generate results.  I thought maybe I could just use 
the rows() method and catch any exceptions for statements that do not generate 
results and then resubmit those statements via execute() but that approach is 
pretty ugly and seems to generate error messages that are difficult/impossible 
to suppress.

 

If the other SQL methods supported the “hasResults” flag and/or if the 
execute() methods supported metadata results I feel like the overall 
implementation would be improved.

 

Thanks,

Steve

 

 

Reply via email to