Forem: Aleksey Stukalov

Soft Deletion in Hibernate: Things You May Miss

Aleksey Stukalov — Mon, 30 Aug 2021 10:09:34 +0000

Soft Deletion is a commonly used pattern in enterprise applications. Hibernate is a widely used persistence framework in the Java ecosystem. Therefore, it is not surprising that Hibernate provides a way to implement soft deletion. However, this approach has some awkward aspects, which are not highlighted by the docs and articles on that matter. In this article, we will dive into some details that you may miss.

@SQLDelete + @Where

If you Google 'soft deletion hibernate,' you’ll most likely find tutorials by Eugen Paraschiv, Vlad Mihalcea, or Thorben Janssen. They suggest using Hibernate @SQLDelete and @Where annotations which let you automatically set the deleted flag and filter by it:



@Entity
@Table(name = "article")
@SQLDelete(sql = "update article set deleted=true where id=?")
@Where(clause = "deleted = false")
public class Article {
   @Id
   @GeneratedValue(strategy = GenerationType.SEQUENCE)
   @Column(name = "id", nullable = false)
   private Long id;

   @Column(name = "deleted", nullable = false)
   private Boolean deleted = false;

   // other properties, getters and setters omitted
}

@SQLDelete takes a native SQL query that is executed whenever a Hibernate-managed entity gets deleted. @Where takes a condition and appends it to 'select' queries automatically, allowing you to filter entities based on the deleted attribute automatically.

This looks like a silver bullet, however, the devil is in the details. Plain queries will work absolutely fine, but what's going to happen with associations?

Problems With Associations

Let's think for a second, what behavior would you expect when you fetch an entity that has an association field to a collection, where some entities were soft-deleted, or to a single soft-deleted entity? In fact, there is no wide range of options. Rather, you want deleted records to be excluded or included in the resulting dataset. And your choice may vary depending on the use case. E.g., we have a collection of items in the e-store cart. Deleting an item we would expect this to disappear from the order, right? However, deleted products should stay in the historical invoices. Isn't it a contradiction?

Let's examine how the @Where + @SQLDelete solution works for different types of associations, fetch the type and API used for executing the query. See the ER diagram below, we are going to use it for our further experiments:

The Article has a ManyToMany association to Author, OneToMany association to Comment, and a OneToOne association to ArticleDetails. The question is, what should happen if one of them is deleted but still referenced from a live entity?

OneToMany and ManyToMany

Hibernate filters out deleted entities from all ToMany associations. If you run the following code before and after marking one author entity as deleted, the number of names printed will change:



articleOptional.ifPresent(article -> {
   article.getAuthors()
           .forEach(author -> logger.info(author.getName()));
});

The good news, such behavior consistently happens regardless of the fetching type (lazy or eager) and way of calling it (via entityManager, Criteria API, Spring Data JPA, etc.).

Lazy ManyToOne and OneToOne

Let's imagine that we soft-delete an article from our example. However, we don't want to delete comments under this article, so that when recovering the article it appears back with its comments.



@Entity
@Table(name = "comment")
public class Comment {
   ...
   @ManyToOne(fetch = FetchType.LAZY)
   @JoinColumn(name = "article_id")
   private Article article;
   ...
}

Now, let's try to fetch a comment associated with the soft-deleted article:



Optional<Comment> comment = commentRepository.findById(id);
comment.ifPresent(com -> logger.info(com.getArticle().getText()));

If you add a breakpoint after the first line, you’ll see that the article is initialized with a proxy.

Well, this is understandable since Hibernate does not know in advance whether the entity is deleted or not. Once you call com.getArticle().getText(), the EntityNotFoundException is thrown! Is that what you would expect?

Eager ManyToOne and OneToOne

Let’s repeat the same experiment but change the fetch type to the Eager mode. Now comments get fetched with their article and no proxy is required. Hibernate knows for sure that the article is deleted. Let's run the same test:



Optional<Comment> comment = commentRepository.findById(id);
comment.ifPresent(com -> logger.info(com.getArticle().getText()));

The associated soft-deleted article is silently loaded with no exception with the deleted attribute set to true:

Such inconsistent behavior can be easily explained. The eager fetch type makes Hibernate join the article table right away. So, Hibernate has a choice to throw the EntityNotFoundException right away or load it normally. Since the article is loaded, the @Where mechanism is out of power, and Hibernate simply maps it to the target class.

Let's fetch a collection of comments:



Iterable<Comment> comments = commentRepository.findAll();

Now we get EntityNotFoundException again! This starts to happen again because findAll leads to separate queries for the associated Article entities, as noted here.

Any time a soft-deleted entity gets fetched by a separate query it causes the above exception. This happens because generating a separate query Hibernate applies the @Where clause, which makes it impossible to find a soft-deleted entity. Obviously, such queries always return an empty result, which, in its turn, causes EntityNotFoundException.

What's even more amusing is that you need to experiment to see how exactly Hibernate will fetch data using different APIs. So, using QueryDSL you are going to hit the same exception fetching a collection or a single entity. At the same time, criteria API returns the deleted entity for eager OneToOne but throws EntityNotFoundException for eager ManyToOne. Total mess, isn't it?

Way to Avoid EntityNotFoundException

There is a cure against the annoying EntityNotFoundException. Hibernate introduces the @NotFound annotation, which can change the behavior from raising the exception to silently setting null into the association field.

This may look like a panacea, however, it brings a significant downside: all ToOne associations become eagerly fetched, regardless of the declared fetch type. This fact may massively impact the performance of your application.

Problems with Constraints and Indexes

Both deleted and live entities will share unique constraints and indexes. Hence, creating regular indexes will not work any longer. Let's take an example where an author has a unique login constraint. After soft-deletion, our record stays in the table, so no live author can reuse the same login of the deleted ones.

You are lucky if you use PostgreSQL and can use partial indexes:



CREATE UNIQUE INDEX author_login_idx ON author (login) 
WHERE deleted = false;

But if you build your application on top of MySQL, this task turns out to be unsolvable.

Conclusion

As you may see, Soft Deletion is an easy pattern to understand, but not that easy to implement. Seems there is no ideal implementation for soft deletion. At least Hibernate doesn't provide one.

In simple cases, you definitely can use @SQLDelete + @Where. However, in the case when soft-deleted entities appear in OneToOne and ManyToOne associations, you barely can count on the consistent behavior. Simply changing the fetch type, or introducing @EntityGraph, or porting your query from Criteria API to QueryDSL or whatever else is likely to change the result: from getting the unexpected exception to the unexpected successful load of the deleted entity or even getting the unexpected null.

Lombok and JPA: What may go wrong?

Aleksey Stukalov — Mon, 19 Apr 2021 16:35:58 +0000

Lombok is a great tool that makes your Java code concise and clean. However, there are a few things to consider when using it with JPA. In this article, we’ll look at how the misuse of Lombok can hurt the performance of JPA applications or even crash them, and how to avoid that but still gain the benefits of using Lombok.

We develop JPA Buddy – a plugin for IntelliJ IDEA designed to make the use of JPA easier. Before writing a single line of code for it, we went through a ton of projects on GitHub to understand how people work with JPA. Turns out, a lot of them use Lombok for their entities.

It is absolutely fine to use Lombok in your JPA projects, but it has some caveats. Analyzing the projects, we see people stumble into the same pitfalls over and over again. This is why we introduced a number of code inspections for Lombok to JPA Buddy. This article shows the most common issues you may face using Lombok with JPA entities.

Broken HashSets (and HashMaps)

Entity classes often get annotated with @EqualsAndHashCode or @Data. The documentation of @EqualsAndHashCode states:

By default, it'll use all non-static, non-transient fields, but you can modify which fields are used (and even specify that the output of various methods is to be used) by marking type members with @EqualsAndHashCode.Include or @EqualsAndHashCode.Exclude.

Equals()/hashCode() implementation for JPA entities is a sensitive subject. Naturally, entities are mutable. Even the id of an entity is often generated by a database, so it gets changed after the entity is first persisted. This means there are no fields we can rely on to calculate the hashCode.

For example, let’s create a test entity:

@Entity
@EqualsAndHashCode
public class TestEntity {

   @Id
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   @Column(nullable = false)
   private Long id;

}

And execute the following code:

TestEntity testEntity = new TestEntity();
Set<TestEntity> set = new HashSet<>();

set.add(testEntity);
testEntityRepository.save(testEntity);

Assert.isTrue(set.contains(testEntity), "Entity not found in the set");

The assertion in the last line fails, even though the entity is added to the set just a couple of lines above. Delomboking the @EqualsAndHashCode gives us the following:

public int hashCode() {
   final int PRIME = 59;
   int result = 1;
   final Object $id = this.getId();
   result = result * PRIME + ($id == null ? 43 : $id.hashCode());
   return result;
}

Once the id is generated (on its first save) the hashCode gets changed. So the HashSet looks for the entity in a different bucket and cannot find it. It wouldn’t be an issue if the id was set during the entity object creation (e.g. was a UUID set by the app), but DB-generated ids are more common.

Accidentally Loading Lazy Attributes

As mentioned above, @EqualsAndHashCode includes all the object fields by default. The same is right for @ToString:

Any class definition may be annotated with @ToString to let lombok generate an implementation of the toString() method. By default, it'll print your class name, along with each field, in order, separated by commas.

These methods call equals()/hashCode()/toString() on every field of an object. This can have an unwanted side-effect for JPA entities: accidentally loading lazy attributes.

For example, calling hashCode() on a lazy @OneToMany may fetch all the entities it contains. This can easily harm the application performance. It can also lead to a LazyInitializationException if it happens outside a transaction.

We believe @EqualsAndHashCode and @Data should not be used for entities at all, so JPA Buddy alerts developers:

@ToString can still be used, but all the lazy fields need to be excluded. This can be achieved by placing @ToString.Exclude on the desired fields, or by using @ToString(onlyExplicitlyIncluded = true) on the class and @ToString.Include on non-lazy fields. JPA Buddy has a special action for it:

Missing No-Argument Constructor

According to the JPA specification, all entity classes are required to have a public or protected no-argument constructor. Obviously, when @AllArgsConstructor is used the compiler does not generate the default constructor, the same is true for @Builder:

Applying @builder to a class is as if you added @AllArgsConstructor(access = AccessLevel.PACKAGE) to the class and applied the @builder annotation to this all-args-constructor.

So make sure to always use them with @NoArgsConstructor or an explicit no-argument constructor:

Conclusion

Lombok makes your code look nicer, but as with any magic-like tool, it is important to understand how exactly it works and when to use it. You can also rely on development tools to predict potential issues for you. Otherwise, you might accidentally hurt the performance of your application or even break something.

When working with JPA and Lombok, remember these rules:

Avoid using @EqualsAndHashCode and @Data with JPA entities;
Always exclude lazy attributes when using @ToString;
Don’t forget to add @NoArgsConstructor to entities with -@Builder or @AllArgsConstructor.

Or let JPA Buddy remember them for you: its code inspections are always at your service.

Hibernate Naming Strategies: JPA Specification vs Spring Boot Opinionation

Aleksey Stukalov — Tue, 16 Mar 2021 12:59:34 +0000

Each time we inject a dependency into our project, we sign a contract, which often has lots of hidden things "written in the fine print". In this article, we will take a look at something you could miss when signing a tripartite contract between you, Hibernate and Spring Boot. We will talk about naming strategies.

Defaults in JPA Naming

The ultimate rule about defaults: they must be intuitive. Let's check if this rule applies to a standard Spring Boot application with default configuration using Hibernate as a JPA implementation. Imagine you have an entity “PetType”. Let’s guess what table name in the database it is associated with.

First example:



@Entity
public class PetType {
  // fields omitted
}

To me, the most intuitive table name would be the class name, which is PetType. Running a test against PostgreSQL we find out that the associated table name is actually pet_type.
Let’s set the name explicitly using @Table:



@Entity
@Table(name = "PetType")
public class PetType {
  // fields omitted
}

This time we expect to see PetType for sure, but if we run the test… pet_type again!

Well, let's wrap the table name in quotes. This should keep not only the defined name but also the case.



@Entity
@Table(name = "\"PetType\"")
public class PetType {
  // fields omitted
}

Again, our expectations were wrong, and we see “pet_type”, but now in quotes!

Hibernate Naming Strategies

Googling "jpa entity default table name" you’ll most probably stumble onto the following result:

The JPA default table name is the name of the class (minus the package) with the first letter capitalized. Each attribute of the class will be stored in a column in the table.

It is exactly what we expected to see in the first example, isn't it? Obviously, something breaks the standard.

Let's dive deeper into Hibernate. According to the documentation, there are two interfaces responsible for naming your tables, columns etc. in Hibernate: ImplicitNamingStrategy and PhysicalNamingStrategy.

ImplicitNamingStrategy is in charge of naming all objects that were not explicitly named by a developer: e.g. entity name, table name, column name, index, FK etc. The resulting name is called the logical name, it is used internally by Hibernate to identify an object. It is not the name that gets put into the DB.

PhysicalNamingStrategy provides the actual physical name used in the DB based on the logical JPA object name. Effectively, this means that using Hibernate you cannot specify database object names directly, but only logical ones. To have a better understanding of what's happening under the hood, see the diagram below.

Hibernate default implementations of these interfaces are ImplicitNamingStrategyJpaCompliantImpl and PhysicalNamingStrategyStandardImpl. The former generates logical names in accordance with the JPA specification, and the latter uses them as physical names without any modifications. This is best described in the documentation:

JPA defines inherent rules about implicit logical name determination. If JPA provider portability is a major concern, or if you really just like the JPA-defined implicit naming rules, be sure to stick with ImplicitNamingStrategyJpaCompliantImpl (the default).
Also, JPA defines no separation between logical and physical name. Following the JPA specification, the logical name is the physical name. If JPA provider portability is important, applications should prefer not to specify a PhysicalNamingStrategy.

However, our application shows different behaviour. And this is why. Spring Boot overrides Hibernate default implementations for both interfaces and uses SpringImplicitNamingStrategy and SpringPhysicalNamingStrategy instead.

Effectively, SpringImplicitNamingStrategy copies the behaviour of ImplicitNamingStrategyJpaCompliantImpl with only a minor difference in join table naming. So, it must be SpringPhysicalNamingStrategy that produces the results we’ve seen. The documentation states the following:

By default, Spring Boot configures the physical naming strategy with SpringPhysicalNamingStrategy. This implementation provides the same table structure as Hibernate 4: all dots are replaced by underscores and camel casing is replaced by underscores as well. Additionally, by default, all table names are generated in the lower case. For example, a TelephoneNumber entity is mapped to the telephone_number table.

Basically, it always transforms camelCase and PascalCase to snake_case. In fact, using it isn’t possible to work with non_snake_case at all. Personally, I would never use camelCase or PascalCase for naming database objects, but there are DB admins who would. If your Spring Boot application deals with a third-party database where at least one table or column is defined in a pascal or camel case, the default Spring Boot setup will not work for you. So, make sure the used physical naming strategy supports the given database naming convention. Learn how to change the default naming strategy in this article or, if required, learn how to provide your own implementation here.

So, Hibernate complies with the JPA spec and Spring Boot doesn’t. This may look like a bug, but Spring Boot claims to be an opinionated framework. In other words, it has the full right to apply its own opinion over all standards and specs of the technology used under the hood. For a developer this means the following:

Opinionation may override any specification. In other words, specs and standards state how it should be, while the used implementation defines what it actually is.
If something even works by default, you should always learn what this default is and how exactly it works.
Defaults may change with library version upgrade, which can lead to unpredictable side effects.

Conclusion

The magic of default configurations may work until you hit some unexpected behaviour. To avoid such risk, you may prefer explicit definition to implicit use of defaults. So, in our case the recommendation would be:

Always name your JPA objects explicitly, so that no Implicit Naming Strategy affects your code
Use the snake_case for columns, tables, indexes and other JPA objects names in order to avoid their transformation by any implementation of the Physical Naming Strategy
In case of snake_case doesn't work for you (e.g. using a legacy database), set Physical Naming Strategy to PhysicalNamingStrategyStandardImpl

Explicit naming of JPA objects will also prevent database schema from unwanted changes in case of an entity class or a field name refactoring.

You may notice that solving potential problems in runtime we simply transfer responsibilities to developers by introducing naming conventions. Now we need to make sure that all developers follow the same rules. This can be automated by shifting these responsibilities further to development tools.

So, if you use IntelliJ IDEA, you may try JPA Buddy – a plugin intended to help developers with JPA, Hibernate, Spring Data JPA, Liquibase and other related technology. JPA Buddy enables a team to set up agreed code conventions and applies them for newly generated JPA entities.

Creating associations with JPA Buddy

Aleksey Stukalov — Sun, 14 Mar 2021 20:25:48 +0000

Have a look at how easy you can create and modify associations with JPA Buddy!

JPA goes even easier with its Buddy

Aleksey Stukalov — Sat, 13 Mar 2021 18:36:53 +0000

So, Hello World... After almost a year of development, the first version of JPA Buddy has finally been released! This is a tool that is supposed to become your faithful coding assistant for projects with JPA and everything related: Hibernate, Spring Data, Liquibase and other mainstream stack.

“Why would I use it?” - this is a fair question towards any new tool or framework. In short, if you use JPA for data persistence, JPA Buddy will help you to be more efficient. In this article, I'll present an overview of the tool. I hope it will take its fair place among the most loved tools for Java developers, ones who use JPA, Spring, Liquibase and of course the most advanced Java IDE - IntelliJ IDEA.

The Story Behind

We are the creators of CUBA Platform (btw, a few weeks ago it was renamed to Jmix:)) - a rapid application development environment on Java. CUBA Platform is quite a unique product. It has both parts: a framework and a development tool. One of the most loved parts of CUBA Studio (specialized IDE for CUBA) is "Entity Designer" - it amazed over 20 000 members of CUBA community by how easy and fast anyone can design their data model. Even for those who have never heard of JPA, things like creating JPA entities, constraints, DDL scripts become a no-brainer.

Since 2016, when CUBA went open-source we have participated in dozens of conferences all around the world, gathering feedback and getting a better understanding of what developers need. And one of the most annoying questions was - "Can we use your entity designer in our application without CUBA?". I'm happy to announce that with JPA Buddy we managed to change our negative answer towards... yes!

JPA Buddy is noninvasive, it doesn't require any extra dependencies - it is a tool and only a tool. This means you can gain benefits from it not only for new but also for already existing projects which employ JPA for the persistence layer. It works as an addition to your IntelliJ IDEA enabling a number of JPA-related features. JPA Buddy helps you to generate code, find and fix potential bugs, refactor and perform other laborious boilerplate operations.

Scope

Before JPA Buddy got its first line of code we had conducted a survey in order to gather various use cases of JPA and surrounding technology. The result doesn't look very surprising - an average application nowadays is a Spring Boot application with Hibernate as an ORM implementation, Spring Data JPA as the data manipulation mechanism and Flyway or Liquibase for the database migration system. Ah, almost forgot about Lombok... This technology stack became our main focus for the first release.

Speaking about the aim of the instrument we pursued the following targets:

Minimize manual boilerplate coding - the tool should generate code that you would write manually but faster
Save time on reading the documentation - the tool must provide intuitive and self-explanatory visual designers
Leave freedom of choice - the tool must not dictate any particular coding style, but provide various options
Detect potential issues and provide ways to fix the most common problems - the tool should alert a developer about such problems as early as possible, ideally at the coding stage, not in runtime
Provide a data-centric view on a project and convenient navigation between related objects For the first release, we were able to deliver quite a significant number of features covering most aspects of data model development. Good news for those who use Liquibase - it is implemented and available in the first release of JPA Buddy. Not so good news for Flyway users - it is in the high-priority list of features.

In longer-term planning we are going to introduce the following set of features:

Hibernate-specific annotations, like @Where, @NaturalId, @Formula, Hibernate search ones and others…
Visual query designer
Audit using Envers and Spring Data JPA
Reverse engineering of a database schema
Support for Kotlin There are also some features we also keep in mind on the second stage: Quarkus and Micronaut support, REST API and UI generation for CRUD operations.

As you may see, there is a long way ahead and we would much appreciate your help in prioritizing all the above features - don't hesitate to let us know your point of view via our contact form, Twitter or join Discord chat.

Overview

Let me give a short overview of what it looks like. Since you install JPA Buddy you will find 3 additional tool windows: JPA Structure, JPA Palette and JPA Inspector.

JPA Structure

JPA Structure is always available on the bottom-left side. It provides a comprehensive data-centric view of the project. You can use it for many different purposes:

Traverse through the data model. The entity structure is represented in a hierarchical way. You can easily observe and navigate to entities referencing the current one and ones the current entity refers to. This is an extremely useful feature, especially for those who are just diving into an existing project with a large entity graph or for code reviewers, who often see parts of the data model for the first time and have limited time to understand how it is designed.
Create data-related objects: entities, JPA converters / Hibernate types, Spring Data repositories and Liquibase changelog.
Observe related Spring Data repositories for each entity.
View Liquibase changelogs along with their internal structure for easier navigation.
Specify plugin-related settings such as DB connection, persistence units and others, which the plugin was not able to detect automatically.

More features to come…

JPA Palette and Inspector

JPA Palette is sitting at the top right and its content is context-dependent. It is available only when Buddy is ready to offer something for fast code generation. Currently, the tool comes up when editing following objects: JPA Entity, Spring Data repository and Liquibase changelog. Simply find the desired option from the list and double-click on it!

JPA Inspector is placed at the bottom right, beneath the Palette and becomes visible and invisible synchronously with it. The Inspector is also context-dependent. While the Palette gives you a number of options for generating new parts of code, the Inspector is intended to modify already existing code. Here you can see what capabilities you have to tune a selected part of code, e.g. a field of an entity or a statement from a Liquibase changeset.

These features are much helpful for both newbies and experienced users. Juniors can evaluate the full list of options, pick the proper one and generate valid code using intuitive visual designers. Seniors often forget minor things that are not in daily use and Buddy will save a few seconds of their valuable time on searching through the documentation in order to remember the right annotation or syntax.

Liquibase Integration

Good news for those who use Liquibase as a database schema versioning solution. JPA Buddy provides tight integration with it, enabling convenient changelog editing, smart changelogs generation and flexible type management.

First of all, you get a visual designer for editing changelogs. Explore various available commands in the Palette and use the Inspector toolwindow to see different settings that could be applied for the selected statement.

Secondly, you can define your own mappings to match Java types (Converters/Hibernate types) and the ones that should be used for each specific DBMS. Let me give you a few examples when this feature will be extremely useful:

Using a byte array entity field, Hibernate scheme generator as well as Liquibase would map your Byte[] to a quite exotic type OID. I guess quite a few developers would prefer to use bytea instead of the defaultly proposed type. This could be easily solved by specifying bytea as the desired mapping type for byte[].
Using a JPA converter or a Hibernate custom type causes unpredictable behaviour or even failures in Hibernate scheme generator and Liquibase changelog generator. You can define the right type in JPA Buddy to resolve this issue.
Using a String field we may want to map it to nvarchar instead of the default varchar.

All these cases could be traditionally solved by using the columnDefinition attribute, however, this solution would not work for cross-DBMS solutions.

Finally, the most time-saving feature: Liquibase changelogs generator. From my experience (proved by the previously-mentioned survey) there are two major ways of creating Liquibase changelogs:

Writing changelogs manually.
Generating scripts by comparing two databases, source one (representing the actual state of the model) against the target one (with the previous state of the model).
For those who prefer the first option JPA Buddy enables the already mentioned changelog designer.

The second option seems to be the most used one. So, we compare two databases. The target database is relatively easy to obtain, for instance, we can simply create a dump of the production environment. Problems come with the source database. Let's start with a minor issue: it may happen that the database used for development on the developer's laptop is not the same DBMS type as the production one. Well, this can be solved by, for example, running MS SQL in Docker on Mac. More serious thing is that it is hard to find a "clean" source database, as it normally gets formed while development by the Hibernate schema generator. Often, this leads to a bunch of garbage tables and attributes, which finally appear in the production DB. To avoid such junk you would need to spend another hour or two reviewing your database schema before running the generation of the changelogs.

JPA Buddy offers an admirable function of generating changelogs directly by comparing your JPA entities with the target database (or a snapshot of the target database). You can run H2 for development purposes and still provide correct changelogs for Oracle or MS SQL or whatever you use in production. This ensures that if you have garbage in changelogs, this is exactly garbage you have in your source code. All you need is to keep your data model clean and be sure that migration will not bring unwanted artefacts to the production database.

Another feature of the changelogs generator is the ability to filter resulting statements into 3 categories:

containing only safe statements, ones which cannot fail while update or ruin your application, e.g. adding a new column
containing statements that may fail while update, but not lead to data-loss, e.g. applying a unique constraint
containing statements that will cause data-loss, e.g. dropping a table or a column

You decide how to split such statements: put them into separate changelogs or just tag them with some label or context.

Conclusion

This article presents an overview of the very first release of JPA Buddy. Obviously, as with any brand new product, it cannot avoid some issues and defects. Today the main focus is polishing the existing functionality, detecting and implementing essential features we miss. Directly speaking, we would like to inspire you to become an early adopter and form an initial community of enthusiasts. Install JPA Buddy, try it out and share your feedback with the development team - this will help a lot to steer the product in the right direction!