On Apr 7, 1:43 pm, Lukas Eder <[email protected]> wrote: > > The only reference that is going to be transient in jOOQ 1.5.7 is a > Configuration's reference to a java.sql.Connection. In order to > execute an org.jooq.Query after serialisation/deserialisation, you > will have to re-attach it to a Configuration (= Factory), so it can be > executed in the context of that Configuration. > > In short: Your use case should be working out with version jOOQ 1.5.7
That's great! > > This would really make > > things a lot easier in web environments like Wicket. > > I'm curious about the details of that. How do you integrate jOOQ with > Wicket? If I know more about your use case, I could anticipate other > issues that might arise... Well i'm currently just trying to write a very simple database driven web application without too much complexity and/or "layers". It's just plain Wicket java code, jOOQ, a PostgreSQL database and some simple classes that i wrote to make coupling of Wicket & jOOQ less verbose - but nothing "special" that couldn't be done without those classes. I'm using a custom wicket request cycle that opens and closes database connections from a connection pool and i use a jOOQ factory around that connection. jOOQ Record objects work great with Wicket's CompoundPropertyModel - in short, if you have <span wicket:id="title"/> in your markup, and some Record with a getTitle() method, you can simply wrap a CompoundPropertyModel around the Record and associate that model with the page and wicket Wicket will almost automatically fill in the value of the "title" field in the "title" tag in the markup. The problem with non-serializable records is that since Wicket is a 'stateful' web framework, it needs to store the 'state' of a page using serialization between HTTP requests, because it often needs to re-render a page after a link or button is clicked or something like that. I could off course copy all primitive values from a Record in my own serializable object, or make sure that only the primary key of a record is serialized (if it has one!) and re-request the data from the database on the next request, but it would be a lot easier if the Record itself would be serializable. Another advantage of having a serializable Record would be that i could in some situations simply call delete() on a deserialized UpdatableRecord after a user clicked a 'delete' button or even just call store() on it after the user updated values in a form - since the record is directly coupled to the form's "Model", the record object already has the changed values in it. The problem with non-serializable unexecuted queries is almost the same: in some situations i want the data on the page to update whenever the page is re-rendered, so i would like to attach a custom model that holds the query itself to a page, so that the query is re- executed every time the page is reloaded. I'm currently using my own abstract wicket Model class for this on which i have to override a "public Select getQuery()" method every time i use it, but if a query would be serializable, i could just pass the query as an argument to a non-abstract version of this class.
