Though there are some nice features in mybatis that my coworkers like
overall I can't stand that much XML.

Now to answer your question.  Personally the built in functionality
supports most of my needs:

http://www.jooq.org/doc/3.8/manual/sql-execution/fetching/pojos/

http://www.jooq.org/doc/3.8/manual/sql-execution/fetching/pojos-with-recordmapper-provider/

But if that's not enough I believe what Lukas was referring to was:

https://blog.jooq.org/2013/08/06/use-modelmapper-and-jooq-to-regain-control-of-your-domain-model/

Hope this helps.

--
Samir Faci




On Tue, May 31, 2016 at 7:54 PM, musicsquad <[email protected]>
wrote:

> Hi all,
>
> I've had early discussion with Lukas earlier about this, but I'll write
> the background first and would like some input from you all.
>
> What I've been trying to get from ORM is to completely separate SQL part
> and application code part (dont we all).
> I dislike Hibernate's HQL or any other SQL-phobe ORMs and opted for
> mybatis. but with mybatis, application code bleeds to SQL part like so:
>
> <mapper namespace="project.electric.asia">
>
>     <select id="getAll" resultType="com.test.User">
>        SELECT * FROM USERS
>    </select>
>
>     <select id="getByCountry" parameterType="string" resultType=
> "com.test.User">
>        SELECT * FROM USERS
>         LEFT JOIN ADDRESS ON USERS.id = ADDRESS.USER_ID
>        LEFT JOIN PROJECT ON USERS.id = PROJECT.MEMBER_ID
>        WHERE id = #{id}
>    </select>
>
> </mapper>
>
> see that pesky "resultType" attribute there in "select" element? this is
> just so not right.
>
> secondly, comes the part where we describe how the flat structured
> resultset returned by the query in the above mapper should be mapped to our
> graph-like POJO structure
>
> <resultMap id="userResultMap" type="com.test.User">
>    ....
> </resultMap>
>
>
> and bam, the "com.test.User" strikes again. this resultMap xml should be
> in plain xml (or json would be nice) and should be used universally by not
> only java, but C# or any other OOP language. just like json, we dont need
> to put any information about the target object anywhere in the json, so why
> couple this xml only to one particular application code?
>
> what I have in mind (in ideal world) things should looks like so
>
> 1. the SQL statements (not sure why we use the term "mapper" here. I think
> mapper would be more appropriate for the next component). Files like this
> are located outside application deployment structure (that's war file if
> you're using java)
> <mapper namespace="project.electric.asia">
>
>     <select id="getAll">
>       SELECT * FROM USERS
>   </select>
>
>     <select id="getByCountry" parameterType="string">
>       SELECT * FROM USERS
>        LEFT JOIN ADDRESS ON USERS.id = ADDRESS.USER_ID
>       LEFT JOIN PROJECT ON USERS.id = PROJECT.MEMBER_ID
>       WHERE id = #{id}
>   </select>
>
> </mapper>
>
> bye bye resultType
>
> 2. the resultmap xml (pretty sure we should've used the term "mapper" for
> this one here, not the SQL syntax. perhaps because people usually merge
> these 2 components into 1 file?). These "mappers" are inside war
> deployment, but outside  classes folder. I think xml approach is the better
> choice to annotating your POJOs like crazy since it reduces noise in your
> code and xml is the more loosely coupled way.
> <resultMap id="resultMap.namespace.User">
>    <property objCol="userId" objColType="int" tblCol="user_id"/>
>    <property objCol="username" objColType="string" tblCol="user_name"/>
>    <property objCol="address" objColType="complex">
>        <property tblCol="street_name" objCol="streetName"/>
>        <property tblCol="street_number" objCol="streetNumber"/>
>        <property tblCol="country_code" objCol="countryCode"/>
>    </property>
>     <property objCol="projects" objColType="complex" isArray="true">
>        <property tblCol="project_id" objCol="Id" objColType="string"/>
>        <property tblCol="project_name" objCol="Name" objColType="string"/>
>        <property tblCol="project_start_date" objCol="startDate" objColType
> ="localDate"/>
>    </property>
> </resultMap>
>
> again, bye bye com.test.User
>
> 3. and finally the client code will look like this:
>
> List<Users> myTeam = ORMSession.execute("project.electric.asia.getByCountry", 
> 65, "resultMap.namespace.User",User.class);
>
> the second param (65) is the parameter "country code" to be transmitted in
> the SQL statement.
>
>
> for component 1 (SQL statement), Lukas chose the database view option. I
> completely forgot about that technology in database and I think it will
> work. that solves the first component
> now, onto the second component, Lukas recommends model mapper. anybody
> knows a good example of this so-called model mapper?
>
> Let me know what you guys think.
>
> Thanks
>
> --
> 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.
>



-- 
Thank you
Samir Faci

-- 
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