Here's some more info about the usecase
case class User(id:Long, email:String, more stuff...)
case class Blog(id:Long, creator:User, more stuff...)
case class BlogUserInfo(user:User, blog:Blog, liked:Option[Boolean], read:Option[Boolean],...)
Each one of these has an entity.
Blog has oneToOne User, User has oneToOne Blog.
BlogUserInfo has OneToOne User and OneToOne Blog relations.
BlogUserInfo is a join table that contains some extra info about a user-blog relation such as:
did the user read this blog? did he "like" it? more stuff...
I'm creating a play action that returns json info back with Blogs and the current logged in user Info about them. So the client can tell if the user already read/liked that blog...
the query is something like:
b.*, u.*, bu.*
blogs b left join users u on (b.creator_id = u.id
left join users_blogs bu on (bu.blog_id=b.id
where bla bla bla
so the query actually returns info about 3 entities - (blog, user, bloguserinfo).
or actually only about 2 entities, (blog, bloguserinfo).
Because user can be folded into the Blogs User relation.
Now that I think about it perhaps a simple solution using the ORM would be to add a lazy relation of oneToMany from Blog to BlogUserInfo and then with this kind of query the Many side of the relation will actually only be one result.
So Blog entity would infact hold all that is needed - blog info, creator info, blog-loggeduser info.
Nevertheless, sometimes the complexity of queries cannot be reached with an ORM and so we have to resort to lower level apis.
In these cases I would be interested to know if it's possible to reuse the ORM mappings.
I imagine something like this flow:
1. make a query like the above.
2. get the resultset( or List<Map>)
3. retrieve the mapper for Entity A
4. create Model A by sending columns a,b,c,d,e to Entity A mapper
5. retrieve mapper for Entity B
6. create Model B by sending other cols to Entity B mapper
I don't know how feasible all this is, your'e welcome to tell me if I'm just dreaming and this is too complicated :)