On Apr 8, 11:03 pm, Lukas Eder <[email protected]> wrote: > > Would it be possible to add some kind of mechanism that > > "automatically" re-attaches objects to a new factory whenever > > necessary? > > How would you do that? jOOQ doesn't know when / how objects are > serialised. I think that should be the client code's responsibility. > Unless you have an other idea? > > > For instance, i can imagine that you could add some overridable method > > to the Factory class (a "factories" factory) that allows the user to > > define how a new factory should be created whenever needed so that > > whenever a jOOQ object discovers that it's detached, it can call that > > method to get a working factory. That way, a user could "ignore" the > > whole serialization/deserialization process. > > You mean a central (static) Factory registry? jOOQ couldn't ensure > that all Factories in that registry hold valid (open, working) JDBC > Connections. I think, in your case, you will have to write a wrapper > around jOOQ for serialisation / deserialisation...
I wanted to reply to this earlier but i was too busy then and forgot about it later. I was thinking about some kind of "dynamic" Factory registry. For example, you could define an interface or an abstract class called FactoryRegistry that has a getFactory() method, and make it possible to the user to associate a (serializable) object that implements/ extends FactoryRegistry with the initial jOOQ factory. If the factory makes sure that all detachable/Attachable objects that it creates hold a reference to that FactoryRegistry, they could call getFactory() whenever they find out that they are detached and should be attached to perform a task. This way, the implementation of how jOOQ factories and/or JDBC connections are created or fetched is up to the user of the library. He has to make sure that his "registry" returns valid Factories with working JDBC connections. The advantage of such a solution would be that the user of the library could simply define a FactoryRegistry once and from that point on ignore the fact that serialization/deserialization goes on at all. This would be very useful in environments like Wicket, where serialization is not done explicitly by the user but "automagically" in the background by the framework. Please tell me if i'm missing something obvious that makes this impossible ;)
