Greetings, As sort of a side note, you may want to take a look at my Kiss open-source, full-stack web development framework. It includes a super easy to use SQL API that is accessible from Groovy. This API is currently being used in several large-scale, enterprise, production systems. kissweb.org
Blake McBride On Thu, Mar 21, 2024 at 2:20 PM <steve.etchel...@gmail.com> wrote: > 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 > > > > >
