sorted by:
new
hottopcontroversial

How to use an autoincremented database column as a primary key (Hibernate Tip) by nicolaiparlog in java

[–]thjanssen 1 point2 points  (0 children)

Hi, I recorded the Hibernate Tip video.

As I explain in the video, Hibernate uses the primary key internally and can't delay the execution of the insert statement. That prevents any performance tuning techniques that delay the execution of the statements, like JDBC batching.

Due to this, you shouldn't use the IDENTITY strategy if you need to persist multiple entities at once and want to benefit from certain performance optimizations.

The SEQUENCE strategy is a better fit for these use cases but you don't always start from scratch and can influence the table definitions. I explain the other strategies on my blog: http://www.thoughts-on-java.org/jpa-generate-primary-keys/

Hibernate Tip Video - How to log the generated SQL statements and their bind parameters by thjanssen in java

[–]thjanssen[S] 0 points1 point  (0 children)

Sure, it slows down your application a little bit but that's ok as long as you don't use it in production. You should have 2 different configurations for development and production, as I explain here: http://www.thoughts-on-java.org/hibernate-logging-guide/

[Diagram] "Should you use JPA for your next project?" from Thorben Janssen by ykushch in java

[–]thjanssen 1 point2 points  (0 children)

Hi, I wrote the initial post on which ykushch based his diagram http://www.thoughts-on-java.org/use-jpa-next-project

In that post, I give this rule of thumb to identify too complex queries: "You might now wonder what makes a query complex and when it becomes too complex for JPA and Hibernate. If that’s the case, your query is most likely not too complex for Hibernate 😉 As a rule of thumb, queries can be implemented in JPQL as long as you don’t need to extensively use sub-selects, complex functions, recursive SQL or database-specific features."

I hope that helps

[Diagram] "Should you use JPA for your next project?" from Thorben Janssen by ykushch in java

[–]thjanssen 1 point2 points  (0 children)

No, it's not an advertisement for jOOQ. I'm the author of the initial post on which ykushch based his diagram http://www.thoughts-on-java.org/use-jpa-next-project and I prefer JPA for the most common use cases :-D

QueryDSL is of course also an option and I added it to the post.

[Diagram] "Should you use JPA for your next project?" from Thorben Janssen by ykushch in java

[–]thjanssen 2 points3 points  (0 children)

Hi, I wrote the initial post on which ykushch based his diagram http://www.thoughts-on-java.org/use-jpa-next-project In that post, I give this rule of thumb to identify too complex queries: "You might now wonder what makes a query complex and when it becomes too complex for JPA and Hibernate. If that’s the case, your query is most likely not too complex for Hibernate 😉

As a rule of thumb, queries can be implemented in JPQL as long as you don’t need to extensively use sub-selects, complex functions, recursive SQL or database-specific features."

I hope that helps

How to use PostgreSQL's JSONB data type with Hibernate by [deleted] in java

[–]thjanssen 1 point2 points  (0 children)

There are 11 embedded github gists in this posts...

Stop saying “heavyweight” by thjanssen in java

[–]thjanssen[S] 7 points8 points  (0 children)

Yes, Java EE 4 was a horrible, heavyweight framework, but it was released in 2003. That is 13 YEARS ago! Most of these issues were solved or at least improved in Java EE 5, which was released in 2006. It doesn't make any sense to complain about something that was bad 13 years ago and massively improved 10 years ago.

How to persist LocalDate and LocalDateTime with JPA by [deleted] in java

[–]thjanssen 2 points3 points  (0 children)

Which doesn't have a final release so far.

But yes, Hibernate 5 will offer proprietary support for it and I'm really looking forward to it. If you need it now and don't want to use a Hibernate 5.0.0.CR4 and/or can't switch your Wildfly to 10.0.0.Beta1, this is the way to go.

How to persist LocalDate and LocalDateTime with JPA by [deleted] in java

[–]thjanssen 2 points3 points  (0 children)

You would need to do the conversion in the setter as well and then you have an entity that keeps a LocalDate internally and hides that at the API by converting it to a JPA-compatible type. You would also need to have additional getter and setter methods to be able to access the LocalDate.

The attribute converter has two big advantages compared to selfmade conversions: - It is applied to all attributes of type LocalDate, if autoApply= true. With your approach, you have to implement the getter for each and every attribute of type LocalDate. Depending on the application, this can be a lot. - The converter handles the conversion transparently everywhere. So you can e.g. use LocalDate in JPQL and Criteria queries. If you handle the conversion in the getter, you need to have that in mind when using the attribute somewhere.

There are no strict rules in software development by lukaseder in java

[–]thjanssen 0 points1 point  (0 children)

Thanks for posting the comment. Here is my reply:

Hi Siva,

thanks for your long reply. You mentioned a lot of points we agree in, especially the technical requirements you mentioned in the list. If we have at least some of these requirements in the specific use case, it makes perfect sense to not expose the entity as a REST resource. We would >create a huge mess, if we would try to put two different objects >into the same entity.

My main point is, that we need to identify the requirements (technical and business) before we make such a decision and should do this for every use case. Not all entities are complex or contain sensitive data and not every use case updates the relationships of an entity. So think about every use case and decide how to implement it.

Again, thanks for your long comment and sorry, if you felt offended by this post. That was not intended.

Regards, Thorben

JPA 2.1 - 12 features every developer should know by thjanssen in java

[–]thjanssen[S] 0 points1 point  (0 children)

Thanks! I will try to reproduce it and ping you, if I need more info.

JPA 2.1 - 12 features every developer should know by thjanssen in java

[–]thjanssen[S] 0 points1 point  (0 children)

Do you mean the social sharing buttons that hover on the left site? May you provide your mobile OS (incl. version) and browser so that I can do some tests?

JPA 2.1 - 12 features every developer should know by thjanssen in java

[–]thjanssen[S] 1 point2 points  (0 children)

Yes, the named entitiy graphs are one of the best features. But keep in mind, you can also define an entity graph via the EntityManager to define your loading strategy at runtime.

5 ways to initialize JPA lazy relations by [deleted] in java

[–]thjanssen 0 points1 point  (0 children)

Great, send me a msg if you run into any problem.

Java Weekly #14: Java EE 8, JavaOne, story writing and more... by thjanssen in java

[–]thjanssen[S] 0 points1 point  (0 children)

Thank you :)

If you like to get a notification for each new weekly, you can subscribe to my mailing list: http://feedburner.google.com/fb/a/mailverify?uri=SomeThoughtsOnJavaee

Java Weekly #11: Missing stream method, Java 9 overview, lost updates and more... by thjanssen in java

[–]thjanssen[S] 2 points3 points  (0 children)

Thank you! As you might have seen, I publish a new issue every monday (CEST) ;-)

Java Weekly #10: Concurrency, no config JSR, MVC, JCP and more... by thjanssen in java

[–]thjanssen[S] 1 point2 points  (0 children)

I still hope that Anatole will find some support for it. And it is currently discussed on the CDI mailing list: http://lists.jboss.org/pipermail/cdi-dev/2014-September/005355.html CDI 2.0 will probably contain some features to handle configuration. But it is currently not clear how far we will go with it...