> Every time I have tried to tackle these topics with > jOOQ or before jOOQ, I ran into the limitations > imposed by the object-relational impedance mismatch.
I've been wondering whether the mismatch isn't simply a consequence of mapping things wrongly. Caution: Long, potentially incoherent post about totally unusual ways to address the issue; probably useless for Jooq or any other existing O/R framework. I'm sharing this for the perspective, not because it offers any solutions. We currently all map relationships as references. To-one associations as normal member variables, to-many associations as some Collection. That's what we usually want, but not always. Sometimes you really need to do the join on the Java side. Now I'm wondering: Shouldn't we simply follow database logic? Map each primary key to an Id data type. Set up Map<Id,Entity> objects, one for each mapped table. Write the getters that they go through the maps instead of through Java references. No setters - you manipulate relationships by changing Id values, not by bending pointers (and I guess that's the core difference). Essentially, these Maps are just caches of what's in the database. Like with any cache, coherency checking (a.k.a. concurrent update detection a.k.a. optimistic locking) would be the hardest thing to get right. Such an O/R system would be quite different from the usual ones. Just food for thought. Philosophy that doesn't fill anybody's bowl. Thanks for reading :-) -- 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.
