On May 3, 11:00 pm, Lukas Eder <[email protected]> wrote:
> Hello Sander,
>
> I understand what you intend to do. I just don't see (yet) how it's
> possible. Before continuing, I'm sure we agree that providing
> registries is optional, and in case jOOQ couldn't find a registry, it
> will still throw the DetachedException when an unattached object is
> stored/refreshed/deleted/executed, right?
Agreed :)
> Of course, the registry's implementation is up to the user. jOOQ will
> only provide an interface. But how does the magic happen? Say you have
> an attachable A. And you have two databases DB1 and DB2. Now A is
> available in both DB1 and DB2 (by the SchemaMapping functionality). Of
> course, you are right, the attachables can hook into deserialisation,
> so once they are materialised again, they will ask the registry for a
> Configuration or Factory. But what can they pass to the registry? A,
> for instance doesn't know whether it belonged to DB1 or DB2 anymore,
> as that information was session-dependent, or in the scope of jOOQ's
> client code. So how can the registry provide the correct
> Configuration? Or is that entirely up to the client code?
I would say that it's entirely up to the client code. :)
I think that in most simple day-to-day scenarios (one database, one
schema) this won't be too complicated. But even in more complicated
situations, i think it's still manageable.
Let's take a look at your example. If i understand you correctly,
there is one database with two schemata (that's what the SchemaMapping
functionality does, right?). One schema is called DB1, the other one
DB2. Let's say Attachable A is a Record object that refers to a record
in DB1, but the same table exists in DB2. We know that A *could* refer
to DB1 as well as DB2, but before serialization happens we also know
that it *does* refer only to DB1. We know that because A's associated
Factory or Configuration is connected to DB1. A's Factory is connected
to DB1, because we passed a DB1 JDBC connection to that Factory when
we created it. Around that same time, we could have passed a DB1
associated registry to that same factory. By the time that the
deserialization happens, that FactoryRegistry still knows it should
provide a DB1 Factory.
What i'm trying to say: it should be entirely up to the client code :)
Even if you choose another approach than the FactoryRegistry one, i
think the general idea should still be to delegate everything to the
client code, for the simple reason that all those implementation
details should be outside the scope of the jOOQ project, just as the
creation of the initial JDBC connection is now.
> Maybe, you could provide me with a descriptive prototype? Is this what you
> mean?
>
> interface FactoryRegistry {
> void attachMe(Attachable attachable) throws NotAttachableException;
>
> }
Yes, i think something like that would work. I was thinking the other
way around (let the registry provide a new Factory so that the
Attachable can re-attach itself) but this matches better with the
preferred jOOQ way of telling the Factory to re-attach attachables
(Factory.attach(Attachable... attachables)).
