JPQL is similar to SQL, but operates on objects, attributes and relationships instead of tables and columns

what does that actualy mean? that when you run a JPQL query ,it works with Entities/Objects in memory and doesn't hit the database ?

I see that when you run a JPQL query, Hibernate does in fact translate it into SQL that hits the database.

So really what is the difference to native SQL? Is it maybe that the Entity retrieved with JPQL is tracked by the persistence context? But doesn't this also hold true for entitities retrieved through native sql ?

CodePudding user response：

what does that actualy mean?

JPQL syntax evaluates your object's fields rather than the Database fields.

So if you have mapped your field names differently in your database, or if your object is persisted across multiple tables, the ORM will take care of correctly translating your JPQL into SQL.

that when you run a JPQL query ,it works with Entities/Objects in memory and doesn't hit the database ?

The Spring/Hibernate framework will hit the database if the object is not in memory to instantiate it.

So really what is the difference to native SQL?

The theory is once your object model is quite complicated, you want to be able to not have a dependency on the underlying DB or table structure. So JPQL allows you an avenue to decouple you from the underlying DB. In practice however it is not generally super seamless and you will be writing NativeQuery (plain SQL) from time to time.