Persistence With Quarkus Panache
Vložit
- čas přidán 12. 05. 2023
- Quarkus Panache, which is one of my favorite Quarkus-specific features, very conveniently enables persistence for relational databases in your application. In this video, I’ll add persistence to one of my example projects using the Panache repository pattern.
For more information: blog.sebastian-daschner.com/e...
Quarkus video courses: www.sebastian-daschner.com/co... - Věda a technologie
richtiger Ehrenmann !
Great video! Just what I was looking for.
Perfect! Thank you!
What should be the minimum changes to this project to migrate to Reactive Hibernate? Should await be used on all repository methods?
The minimum and most important question to answer would be "why". For most projects, I would argue against using reactive, unless you have a good reason and specific use case.
im a bit new to hibernate in general, and it seems the best way to use hibernate is to generate the entities from the database-schema and use a tool like flyway or liquibase for productive migrations.
Now it seems to me, that when i use Panache instead of Hibernate directly, i need to write the Entities all manually without help of a codegenerator. Is this true? I think it would be more comfortable and also less error-prone if such entities can be generated from the database schema or the other way around.
Well, depends :)
So, first of all, Quarkus Panache is still Hibernate (just with some additional sugar), so all of the code generation still works. Working with Panache (esp. the repository way) doesn't contradict having the entities (or the schema) generated, since plain JPA entities work just fine with Panache. The same is true for the other way around, i.e. generating the schema.
If you'd like to generate the entities and at the same time use a certain structure, e.g. the extends PanacheEntity, then you might need to play around with the generation or, if not supported, generate the entities once and add the extends manually.
When using hibernate reactive with repository pattern I've had this error
java.lang.IllegalStateException: No current Mutiny.Session found
Not an expert with reactive/mutiny but you want to make sure that the transactional context is correct, and that the reactive method chaining is invoked correctly. Maybe this helps: stackoverflow.com/questions/76204327/cannot-persist-data-with-quarkus-hibernate-reactive-panache-entity
Thanks for this video Sebastian , I am using persist method to save one to many relationship entity . For Example : Employee is my main entity and I have @OneToMany relationship with Address Entity . So the problem where I have more number of address like 100+ , its taking lots of time . Is there a way to achieve some batch operation to save some time.
Yes, you could save them one by one in individual transactions (via JTA annotations), maybe you'd need to change the relationships (e.g. to optional) a bit. But I'm not sure whether I'd recommand that approach w/r/t consistency...
Hi man, thanks for the video!
I've done some testing on my own, and have some question:
persist is basically upsert. is there an exclusive insert/update function? the good old query that rejects the operation if the item is already exists when insert, and if the item is not exist when updating
is there an update function that accepts collection? sure updating one by one can be done, but I don't think its effective for large data
Yes, so as we're using an ORM here, it helps if we're not thinking in procedural SQL ways but more on "let me create/modify my Java objects, and JPA/Hibernate/Panache makes sure they'll be persisted in the DB". For the "upsert" that's the reason why this doesn't exist, you then would rather check in Java code if you have such an identity/entry already and only if not make some changes to your Java objects.
For update multiple entities, I wouldn't worry about calling persist multiple times, or in a loop, unless there's an actual performance issue. Since the ORM framework does things a bit differently internally (and generally performs most actions only at tx commit time), I would worry about this topic only when/if you come to it
@@SebastianDaschnerIT If I check in my java whether I already have that impact the performance?
so if I do this operation in a loop, the performance would be just fine? IIRC in the old ways, doing similar query several times is worse than committing a big query once isn't it?
hi!!! i need to get the jdbc url at runtime from a running microservice (not from the properties file)... do you know if it is possible?
Hi, yes you can read the property (it's called quarkus.datasource.jdbc.url, unless you have different datasource setups, see quarkus.io/guides/datasource), either via @ConfigProperty or programmatically via ConfigProvider.getConfig
How is the repository pattern different from the DAO pattern?
Not much actually, here the framework already provides most of the persistence access methods, while in the old days, they typically were implemented in the project (on top of entitymangager or such).