Hello Sander, > A quick release would be great off course but I don't want to rush > you :) I'm already quite happy if i can experiment with the trunk > version.
No worries. With the currently experienced trouble related to the latest HSQLDB version, I'm pretty keen on releasing soon, myself: http://groups.google.com/group/jooq-user/browse_thread/thread/a1e001b682d3c35 > Speaking of which, when i try to compile the current trunk > version of jOOQ on my home PC, i get: [...] > > [... the warning ...] Trunk is very hot at the moment :-) I have experienced inconsistencies before, between compiling jOOQ with Eclipse and with javac. I've come to the conclusion that either one has some severe compiler bugs. I'm not sure which one actually does, the issue is quite tricky. You can check out the bug details here, if you're interested: https://bugs.eclipse.org/bugs/show_bug.cgi?id=340506 In any case, thanks for pointing that out to me. I was planning on updating the wiki anyway, to document using jOOQ in a Netbeans project. So I can fix this, soon: https://sourceforge.net/apps/trac/jooq/ticket/389 > 1 error I can reproduce the error as well. That shouldn't be. Thanks for the hint. In the mean time, please use Eclipse on trunk. I'm not supporting development with Netbeans, yet. > Just to make sure i understand how this is supposed to work - i need > to explicitly call [attachableobject].attach(newJooqFactory) before i > try to use a deserialized jOOQ object, right? The final API usage will include - Factory.attach(Attachable... attachables). - Factory.attach(Collection<Attachable> attachables). > 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... Cheers Lukas
