Hello Stefan

2015-04-18 17:59 GMT+02:00 gantners <[email protected]>:

> Hi,
>
> surrounded by the following Scenario:
>
> Serverside
> MysqlDB  -> DAO -> Spring JDBC Template -> POJO _> ServiceLayer -> RMI
>
> Clientside
> RMI -> ServiceLayer -> Swing GUI
>
> Database consists of entities with foreign keys to other entities.
>
> Currently i have purely dumb entites with just foreign ids in it and load
> those entities separately on Access. As this is becoming unhandy as the
> application grows,
> i would really like to swap over to a more orm solution.
>
> Problem: Due to the fact that rmi is used, Hibernate would only work out
> on serverside with eager loading, as remote lazy loading  is not a good
> idea as stated by their faq´s, even if there
> are some approaches to tackle the session Problem.As i do not like the
> idea of session Management and all the Overhead just for eager loading,
> hibernate is out.
>
> *Now i´m searching an alternative way to easily do the entity in entity
> mapping, at least eager or best lazy without any sessions.*
>
> Given this Situation and a lot of googling, i once again came across jooq.
> (i evaluated it already for another Project, but that did not work out with
> the Project time Frame)
>

I'm sorry to hear it didn't work out the last time. I'm curious, how has
the project time frame worked against a jOOQ integration in your case? Was
there anything that could have been improved from the jOOQ side?

But as Stated in your Manual, jooq does not handle complex data structures:
>
>> jOOQ currently doesn't support more complex data structures, the way
>> Hibernate/JPA attempt to map relational data onto POJOs. While future
>> developments in this direction are not excluded, jOOQ claims that generic
>> mapping strategies lead to an enormous additional complexity that only
>> serves very few use cases. You are likely to find a solution using any of
>> jOOQ's various *fetching modes*
>> <http://www.jooq.org/doc/3.5/manual-single-page/#fetching>, with only
>> little boiler-plate code on the client side
>
>
>
> The question would be, could this Problem be tackled with the use of
> modelmapper or any other Approach, as you stated, that it is likely to find
> a solution in the fetching modes? Currently i do not see one...
>

I'm glad you're asking - there is a very interesting discussion going on in
parallel right now, where a user is attempting to use jOOQ as a native
query builder for Hibernate, and then use Hibernate's mapping
implementation to populate managed entities. The discussion is here:
https://groups.google.com/forum/#!topic/jooq-user/x-NGYEPeetw

jOOQ will not go completely into the ORM direction that you have in mind
for another while. We prefer to better integrate with JPA/Hibernate as far
as mapping and managing of entities is concerned, letting established
frameworks take care of ORM business, so we can focus on a tighter SQL
integration.

We do offer navigation between "child" and "parent" records via the
following API:


   - UpdatableRecord.fetchChild(ForeignKey)
   
<http://www.jooq.org/javadoc/latest/org/jooq/UpdatableRecord.html#fetchChild-org.jooq.ForeignKey->
   - UpdatableRecord.fetchChildren(ForeignKey)
   
<http://www.jooq.org/javadoc/latest/org/jooq/UpdatableRecord.html#fetchChildren-org.jooq.ForeignKey->
   - TableRecord.fetchParent(ForeignKey)
   
<http://www.jooq.org/javadoc/latest/org/jooq/TableRecord.html#fetchParent-org.jooq.ForeignKey->


Is this the "little extra ORM" functionality that you had in mind? Or were
you looking for nested records and nested record collections? I'm afraid,
though, that at some point, session management and first level caching is
inevitable, as you will be leaving "value type land" where SQL is
appropriate, and you'll be entering "object land" where ORMs managing
object identity are better suited... It's a thin line, I'm afraid.

Best Regards,
Lukas

-- 
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/d/optout.

Reply via email to