richtiger Ehrenmann !

Great video! Just what I was looking for.

Perfect! Thank you!

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?

@SebastianDaschnerIT

4 ай бұрын

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

When using hibernate reactive with repository pattern I've had this error java.lang.IllegalStateException: No current Mutiny.Session found

@SebastianDaschnerIT

3 ай бұрын

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

What should be the minimum changes to this project to migrate to Reactive Hibernate? Should await be used on all repository methods?

@SebastianDaschnerIT

11 ай бұрын

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.

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.

@SebastianDaschnerIT

10 ай бұрын

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...

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.

@SebastianDaschnerIT

5 ай бұрын

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.

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

@SebastianDaschnerIT

6 ай бұрын

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

@hzt_rzkyi

6 ай бұрын

@@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?

How is the repository pattern different from the DAO pattern?

@SebastianDaschnerIT

Жыл бұрын

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).