Hi all, If I understand the question, electrotype wants advices on how to move from an object hierarchy tree to a record-based model.
I personally do not use jOOQ, but we have our in-house mechanism which is very similar, so I think I can answer the question. Looking at your example: findPersonById_simple(long id) findPersonById_withAdressCity(long id) findPersonById_withJob(long id) findPersonById_withAdressCityAndJob(long id) ... we do have these but in a more simple version: findPersonById(long id, boolean isLight) so we either get an object containing only what we consider fundamental data, or all sorts of sub-relations. The "light" aspect started to be odd as the product grew, because the granularity of light/full was not enough. We generaly now favor smaller objects, where related data is retrieved as a separate entity. These separate entities are not fields of the main entity. Note that in our case, the bottleneck is generally on the number of such entities, so we have these kinds of calls: findPersonByIds(long[] ids) findPersonAdressCity(Person[] persons) findPersonJobs(Person[] persons) If we have 1000 people for which we want all this data, we only issue 3 queries. In fact, some of the above calls like findPersonByIds may not even go to the database because we have all sorts of caching in place for frequently requested data. And in some specific cases, we even have dedicated upfront calls like "loadPersonsAndJobsCaches" so that individual calls to our persistence layer do not go to the database. That being said, if we find a particular area of the product to have performance issues, we can define new API to retrieve all of this in a single query and return the result as an aggregate (like maps relating all the persons to their jobs, etc.). When saving data, we track what is modified, and issue the right calls on the right objects, eventually using batches. We don't magically process a whole object hierarchy. Please do take note that the above approaches are what works for our product and may not be appropriate for all applications! I also second Khun Yee Fung when he says how useful jOOQ syntax errors are when changing the database: this is a great time saving feature. In fact, because we have those errors, the cost of modifying the database structure dropped to a point that we do not hesitate and aggressively change it whenever we feel it is needed or desirable. I would also like to mention tools or facilities that revolve around jOOQ that are worth considering. For us, the jOOQ Console is what boosted our development. When we have a doubt or database-related issue, we open it, log our requests, see the times they take or the number of rows that are returned, perform some ad-hoc queries to better analize the problem and look at the stack traces to see where in our application the code is misbehaving. We also use the execute listeners to perform all sorts of query manipulations and statistics. One example from our nightly test run is a data import which should be a no-op if the data is already there. So our test imports data in a fresh database, and re-imports it with execute listeners that track insert/update statements with a few known exceptions. It saved us more than once from bad equals() implementations that would result in bloated databases and all sorts of other bugs! Hope this helps, -Christopher On Sat, Jul 27, 2013 at 5:58 PM, Lukas Eder <[email protected]> wrote: > Thanks electrotype, for sharing this on the jOOQ User Group! > Myself, I won't respond to your request here for two reasons: > > 1. I have already given an answer to your SO question. > 2. I am very interested in an "unbiased" feedback from the user group. > > *So please, everyone who is interested in this discussion: * > * > * > Feel free to post your opinion / share your experiences on this topic > > Cheers > Lukas > > 2013/7/27 <[email protected]> > >> Hi! I'm new to JOOQ! >> >> I'm looking for a solution to replace JPA/Hibernate as the persistence >> engine in my new Java web application. I'm looking for something closer to >> SQL and JOOQ seems to be a really good fit! >> >> But I have concerns about how JOOQ can replace Hibernate in some use >> cases, in particular for loading and saving entities that contain children >> entities. >> >> Lukas has already helped me on the question but I would like more >> details. Any help from the JOOQ community would be really appreciated! >> >> Since I already asked my question on StackOverflow, I think the best is >> to link to it rather than to copy it here (and there is a 100 points bounty >> on it!) : >> >> http://stackoverflow.com/questions/17860161/replacing-a-full-orm-jpa-hibernate-by-a-lighter-solution-recommended-pattern >> >> >> >> Thanks a lot in advance for any input! >> >> electrotype >> >> >> -- >> 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. >> >> >> > > -- > 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. > > > -- 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.
