Skip to main content

4 posts tagged with "quarkus"

View All Tags

· 2 min read

In my Quarkus application, I encountered a hiccup with the Panache ORM while implementing and testing a REST service. Specifically, I faced a test failure related to the automatic update of a specifications list after deleting an element from the JSON/Entity. In this blog post, I'll walk you through the issue and demonstrate how GitHub Copilot came to the rescue, streamlining the implementation of a solution.

The Challenge:

The JSON schema for my REST service looked like this:

"id": 1,
"name": "Fanatic Falcon",
"description": "Slalom board",
"specifications" : [
{"id": 10, "name": "Falcom 100", "volume": 100},
{"id": 11, "name": "Falcom 110", "volume": 110},
{"id": 12, "name": "Falcom 120", "volume": 120}

I had a test verifying the number of specifications after the deletion of one of them. However, the Panache ORM didn't automatically update the specifications list after deletion, leading to a failing test.

The Solution:

To address this issue, I needed to implement business logic to delete specifications in the database that were not present in the JSON payload. I documented the logic in a comment and collaborated with GitHub Copilot to generate the code.

Here's a snippet of the code:


// if the number of specifications in the existing board is different than the number of specifications in the updated board
// it means that some specifications have been removed, so we need to delete them
// for this we meed to loop on existing specifications and see if they are in the updated board
// if they are not add them to a list of specs to delete
// then use removeAll on existing board specifications
List<BoardSpecification> specsToDelete = new ArrayList<>();
for (BoardSpecification existingSpec : existingBoard.specifications) {
boolean found = false;
for (BoardSpecification spec : board.specifications) {
if ( {
found = true;
if (!found) {


Check out the video below to witness how I leveraged GitHub Copilot to easily implement the business logic.

Once again, GitHub Copilot has proven to be an invaluable coding companion, significantly enhancing my efficiency and helping me overcome challenges in my coding journey. With its assistance, I navigated through the intricacies of the Panache ORM and successfully resolved the test failure, ensuring the seamless functionality of my Quarkus application.

· 7 min read

Quarkus: Simplifying Cloud File Uploads

In many projects, facilitating user uploads to cloud services is a common requirement. In my current project, I find myself inviting users to seamlessly upload various files, such as profile pictures, GPS track files, or session photos, to the site. To enhance my understanding, I've opted to employ multiple cloud providers —Microsoft Azure Blob Storage, Amazon S3, Google Cloud Storage— allowing me to test and compare their functionalities.

This article guides you through the process of:

  1. Creating a REST service for file uploads using RESTEasy Reactive in Quarkus.
  2. Uploading files to the cloud from a Quarkus application.

To complement this discussion, a complete code example is available on GitHub. This resource serves as a practical reference for learning and experimentation.

GitHub Repository: Quarkus: Uploading Image to the Cloud

· 5 min read

Quarkus: Database Projection with Panache

Welcome back to the second installment of our exploration into Quarkus and Panache! In the previous blog post, we delved into setting default values for Panache entity fields. Now, as we continue refining the website with Quarkus integration, our primary focus shifts to implementing Database Projection with Panache.

Code Example on GitHub:

To accompany this discussion, I've published the complete code example on GitHub, providing you with a hands-on reference for learning and experimentation.

GitHub Repository: Learning Quarkus: Database Projection with Panache

Understanding the data model

For this illustrative example, we'll work with a straightforward data model consisting of two tables: 'boards' and 'brands.' The 'boards' table contains a list of windsurfing boards, while the 'brands' table serves as a reference, linked to the 'boards' table through a foreign key relationship.

Quarkus: Default Values for Panache Entity Fields

· 4 min read

Quarkus: Default Values for Panache Entity Fields

In the ever-evolving landscape of database technologies, my journey led me away from Java ORM projects for a decade, exploring the realms of NoSQL databases like MongoDB, Couchbase, Redis, and even HBase.

Recently, my focus shifted back to Java and, specifically, Quarkus. In this blog post, I'll share my experience migrating part of my site,, from MongoDB to PostgreSQL with Quarkus, highlighting how I tackled my first small challenge of setting default values for Panache entity fields.

Choosing Quarkus and Panache:

Having dabbled with Quarkus during my time at Red Hat in 2019, I decided to delve deeper into it for my personal projects. While familiar with using MongoDB directly with Node.js, working with Quarkus and RDBMS prompted me to opt for Hibernate ORM with Panache, a Quarkus extension offering a simplified and user-friendly API for Hibernate ORM.

I have published the code of this example on GitHub: