I'm trying to use JOOQ to dynamically create some statements once and store them, and then as needed attach them to a connection and bind parameters to them and execute them. In my initial development this seems to be working, and JOOQ has been a great help. At first I was unsure JOOQ was going to give me much value in this particular case, as the table and field names to be used were coming in dynamically and so I was not using the generated classes. (It may be a slightly odd use case, I'll spare you the details!) But then I ran into datatype issues in binding values and formatting result data and found that introspecting the generated classes to get datatypes solved my problems.
Making this work so far has been all well and good, however, in refactoring my proof-of-concept code to really separate the storing and usage of Queries, it occurs to me that seems to be no way to detach queries when I am done with them. I'm not sure this is a pragmatic concern, perhaps it is just aesthetic. I kind of expect the semantics to be consistent and leaving a Query hanging around still attached between uses just seems wrong. And I've realized a pragmatic concern that sort of relates, but is bigger than the attachment issue. What about thread safety? Conceptually I would think I ought to be able to use a constructed representation of a sql statement in multiple threads with different connections simultaneously, but since bind and attach are state-changing operations on the query, surely this ins't the case and I need to rethink by design around saving queries. I suppose I can render the SQL and save that and then instantiate a new Query every time I want to use it. I wonder about the performance cost of doing this, but even that aside this seems...ugly. I guess that brings me not much to a question as a suggestion that perhaps JOOQ API's separation of SQL statement construction and execution is incomplete and could (should, even) be taken a step further. Or am I looking at some of the parts of the API in the wrong way conceptually? (Conceptually this is how I'm looking at it: I see SQL building objects...or objects representing built-SQL, do not need to be and ought not have any state related to execution-specific things like connection attachment or parameter binding and as such inherently ought to be able to be thread-safe with regard to execution, though perhaps not with regard to SQL building which could change state approrpiate for them to carry, i.e. state representing what SQL they equate to.) Is there some different way of doing this that I am missing? Such as if there were a means of cloning a Query...? -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
