DEV Community: Guillaume Mary

A simplified definition of an ORM

Guillaume Mary — Fri, 29 Aug 2025 06:25:16 +0000

"Back to school" is here... (at least in France), but have you ever tried to fit a whole school into an Excel file? 🤔😄

While the question seems strange, this is exactly what an ORM (Object-Relational Mapping) aims to do.

Imagine you're a principal and you have to enter all the students, their parents, teachers, subjects, classes, etc., and most importantly, all the relationships that link them, into your spreadsheet. It's quite a puzzle!

If we were to create an application to help our principal, the ORM would be there to help us distribute these concepts (student, parent, teachers...) into the sheets of the Excel file (more specifically, into the tables of the database). It would then allow us to access them to find out if H.Potter has a Math class on Tuesday from 2 p.m. to 3 p.m., or to retrieve professor McGonagall's students...

The ORM is therefore there to store the elements (student, parent, etc.) and especially their relations, while allowing them to be easily retrieved. It's an essential building block in applications that saves developers a lot of time... but it remains tricky to master. The puzzle it saves you from often comes at the cost of behaviors that are not very optimal for your application's specific case, as an ORM must be generic, capable of handling any domain: cooking recipes and their ingredients, cars and customers of a dealership, medical records of hospital patients, etc.

And clearly, this genericity is not easy to develop since the ORM's algorithms must allow it to be applicable everywhere, with the least amount of effort possible for developers.

This is why you're not hearing about Stalactite right now! 😛 It's going through a difficult phase to account for all possible scenarios... so it's long and complicated! The next version will bring compatibility with Spring-Data, putting it on par with JPA / Hibernate for ease of integration.

So if you want to give me a little encouragement and support me in this endeavor, don't hesitate to "star" the GitHub repo. It's an important indicator of its popularity and my morale! 😄

Strength and honor to all volunteer maintainers of open-source projects! 💪👍

There is no difference between technical debt and washing up

Guillaume Mary — Sat, 25 Jan 2025 08:51:11 +0000

We always have better things to do than deal with them: Implement new features or watch a series / go out with friends / play sports
When they pile up, they are harmful: dirty dishes attract insects, technical debt generates bugs
They have a snowball effect: new features are increasingly complicated to implement, so we hurry up and generate even more debt.
If you want to cook while there are dishes in the sink, you don't dare to do the day's dishes, so you leave them in the sink too
Only people who live with them can handle them: no one but you can handle your dishes, no one but the developers of the debt can handle the code, losing them is a disaster and the new ones will be demotivated
One day someone will have to deal with them: imagine you accumulated so many dishes that it is no longer possible to access the kitchen, no buyer will want your apartment (if they see the dishes, meaning they did a technical audit during the company buyout), or will ask for a discount.

Here ends the analogy: in IT there are no dishwashers 😉 No machine is there to help you process your technical debt… well, you can still try with AI, I'll let you write the prompt 🙄

Original post (in French): https://www.linkedin.com/posts/guillaume-mary-692b578a_il-ny-a-pas-de-diff%C3%A9rence-entre-la-dette-activity-7268171568004968448-JEfB?utm_source=share&utm_medium=member_desktop

Introducing Stalactite ORM

Guillaume Mary — Mon, 20 May 2024 12:34:24 +0000

Java ORM world is very steady and few libraries exist, but none of them brought any breaking change over the last decade. Meanwhile, application architecture evolved with some trends such as Hexagonal Architecture, CQRS, Domain Driven Design, or Domain Purity. Stalactite tries to be more suitable to these new paradigms by allowing to persist any kind of Class without the need to annotate them or use external XML files: its mapping is made of method reference.

As a benefit, you get a better view of the entity graph since the mapping is made through a fluent API that chains your entity relations, instead of spreading annotations all over entities. This is very helpful to see the complexity of your entity graph, which would impact its load as well as the memory. Moreover, since Stalactite only fetches data eagerly, we can say that what you see is what you get. Here is a very small example:

MappingEase.entityBuilder(Country.class, Long.class)
    .mapKey(Country::getId, IdentifierPolicy.afterInsert())
    .mapOneToOne(Country::getCapital, MappingEase.entityBuilder(City.class, Long.class)
        .mapKey(City::getId, IdentifierPolicy.afterInsert())
        .map(City::getName))

First Steps

The release 2.0.0 is out for some weeks and is available as a Maven dependency, hereafter is an example with HSQLDB. For now, Stalactite is compatible with the following databases (mainly in their latest version): HSQLDB, H2, PostgreSQL, MySQL, and MariaDB.

<dependency>
   <groupId>org.codefilarete.stalactite</groupId>
   <artifactId>orm-hsqldb-adapter</artifactId>
   <version>2.0.0</version>
</dependency>

If you're interested in a less database-vendor-dedicated module, you can use the orm-all-adapter module. Just be aware that it will bring you extra modules and extra JDBC drivers, heaving your artifact.

After getting Statactite as a dependency, the next step is to have a JDBC DataSource and pass it to a org.codefilarete.stalactite.engine.PersistenceContext:

org.hsqldb.jdbc.JDBCDataSource dataSource= new org.hsqldb.jdbc.JDBCDataSource();
dataSource.setUrl("jdbc:hsqldb:mem:test");
dataSource.setUser("sa");
dataSource.setPassword("");
PersistenceContext persistenceContext = new PersistenceContext(dataSource, new HSQLDBDialect());

Then comes the interesting part: the mapping. Supposing you get a Country, you can quickly set up its mapping through the Fluent API, starting with the org.codefilarete.stalactite.mapping.MappingEase class as such:

EntityPersister<Country, Long> countryPersister = MappingEase.entityBuilder(Country.class, Long.class)
    .mapKey(Country::getId, IdentifierPolicy.afterInsert())
    .map(Country::getName)
    .build(persistenceContext);

the afterInsert() identifier policy means that the country.id column is an auto-increment one. Two other policies exist: the beforeInsert()for identifier given by a database Sequence (for example), and the alreadyAssigned() for entities that have a natural identifier given by business rules,
any non-declared property is considered transient and not managed by Stalactite. The schema can be generated with the org.codefilarete.stalactite.sql.ddl.DDLDeployer class as such (it will generate it into the PersistenceContext dataSource):

DDLDeployer ddlDeployer = new DDLDeployer(persistenceContext);
ddlDeployer.deployDDL();

Finally, you can persist your entities thanks to the EntityPersister obtained previously, please find the example below. You might notice that you won't find JPA methods in Stalactite persister. The reason is that Stalactite is far different from JPA and doesn't aim at being compatible with it: no annotation, no attach/detach mechanism, no first-level cache, no lazy loading, and many more. Hence, the methods are quite straight to their goal:

Country myCountry = new Country();
myCountry.setName("myCountry"); 
countryPersister.insert(myCountry); 
myCountry.setName("myCountry with a different name"); 
countryPersister.update(myCountry); 
Country loadedCountry = countryPersister.select(myCountry.getId()); 
countryPersister.delete(loadedCountry);

Spring Integration

There was a raw usage of Stalactite, meanwhile, you may be interested in its integration with Spring to benefit from the magic of its @Repository. Stalactite provides it, just be aware that it's still a work-in-progress feature. The approach to activate it is the same as for JPA: enable Stalactite repositories thanks to the @EnableStalactiteRepositories annotation on your Spring application. Then you'll declare the PersistenceContext and EntityPersister as @Bean :

@Bean
public PersistenceContext persistenceContext(DataSource dataSource) {
    return new PersistenceContext(dataSource);
}

@Bean
public EntityPersister<Country, Long> countryPersister(PersistenceContext persistenceContext) { 
    return MappingEase.entityBuilder(Country.class, long.class) 
            .mapKey(Country::getId, IdentifierPolicy.afterInsert())
            .map(Country::getName)
            .build(persistenceContext);
}

Then you can declare your repository as such, to be injected into your services :

@Repository
public interface CountryStalactiteRepository extends StalactiteRepository<Country, Long> {
}

As mentioned earlier, since the paradigm of Stalactite is not the same as JPA (no annotation, no attach/detach mechanism, etc), you won't find the same methods of JPA repository in Stalactite ones :

save : Saves the given entity, either inserting it or updating it according to its persistence states
saveAll : Same as the previous one, with a massive API
findById : Try to find an entity by its id in the database
findAllById : Same as the previous one, with a massive API
delete : Delete the given entity from the database
deleteAll : Same as the previous one, with a massive API

Conclusion

In these chapters we introduced the Stalactite ORM, more information about the configuration, the mapping, and all the documentation are available on the website.

The project is open-source with the MIT license and shared through Github.

Thanks for reading, any feedback is appreciated!

Stalactite ORM 2.0.0 is out ! 🚀

Guillaume Mary — Sun, 24 Mar 2024 18:31:25 +0000

Two years after the very first version, Stalactite ORM is back with a 2.0.0 version released ! 🚀😊

As a reminder (legit one !), it has a new approach compared to JPA :

mapping is defined by method references instead of Annotations or XML
its fluent API helps you see the complexity of you graph
it eagerly fetches your relations to avoid hidden sql queries

Here are some of new features :

composite-keys
many-to-many relations
Map mapping
Spring intégration

To give it a try, see documentation here

Stalactite ORM 1.0.0 is out !

Guillaume Mary — Sun, 20 Mar 2022 09:54:12 +0000

After many years of dev, Stalactite ORM is finally released ! It has a brand new approach about persistence :

mapping is defined by method references instead of Annotations or XML
its fluent API helps you see the complexity of you graph
it eagerly fetches your relations to avoid hidden sql queries

Here is a short view of what can be achieved with it :

DataSource dataSource = ... // use whatever JDBC DataSource you want
PersistenceContext persistenceContext = new PersistenceContext(dataSource, new HSQLDBDialect());

EntityPersister<Country, Long> countryPersister = MappingEase.entityBuilder(Country.class, long.class)
    .mapKey(Country::getId, IdentifierPolicy.afterInsert())
    .map(Country::getName)
    .map(Country::getDescription)
    .mapOneToOne(Country::getPresident, MappingEase.entityBuilder(Person.class, long.class)
        .mapKey(Person::getId, IdentifierPolicy.afterInsert())
        .map(Person::getName))
    .build(persistenceContext);

Country country = new Country(42L);
country.setPresident(new Person(12L));
countryPersister.persist(country);

// you can also map an SQL query to build a projection
List<Car> allCars = persistenceContext.newQuery("select id, model, rgb from Car", Car.class)
    .mapKey(Car::new, "id", long.class)
    .map("model", Car::setModel)
    .map("rgb", Car::setColor, int.class, Color::new)
    .execute();

Give it a try, see documentation here