Vidocq Documentation

Mansart cible le standard (Jakarta Data 1.0 + Jakarta Persistence 3.2), pas les extensions propriétaires. La migration depuis Spring Data est triviale — la spec Jakarta Data a explicitement repris les conventions Spring Data. Hibernate / EclipseLink demande plus de travail si l’application utilise des features hors spec (custom dialects, listeners, événements).

Depuis Spring Data JPA

Spring Data Mansart Jakarta Data Note

org.springframework.data.repository.CrudRepository

jakarta.data.repository.CrudRepository

API standardisée — signatures très proches.

@org.springframework.stereotype.Repository

@jakarta.data.repository.Repository

Sémantique différente : Jakarta Data scope = bean repository, pas exception translator.

Méthodes dérivées (findByXxx)

Identiques

Convention reprise par Jakarta Data.

@Query("SELECT b FROM Book b WHERE …​")

@Query("FROM Book WHERE …​") (JDQL)

JDQL plus simple que JPQL — le SELECT initial est implicite.

Pageable / Page<T>

PageRequest / Page<T>

Sémantique identique. PageRequest.afterKey(…​) pour keyset.

@Transactional (Spring)

@jakarta.transaction.Transactional

Six TxType standards. Pas de support de propagation = NESTED (savepoints) en v1.

JpaRepository<T, ID>

BasicRepository<T, K> ou CrudRepository<T, K>

Pas de findAll(Sort) — utiliser @OrderBy ou un findAllByOrderByXxxAsc.

Migrer depuis Spring Data est le chemin le plus court. Les noms de méthodes dérivés et les @Query JDQL transposent ligne pour ligne dans la majorité des cas.

Depuis Hibernate ORM 6/7

Hibernate Mansart Note

SessionFactory / EntityManagerFactory

MansartManagerFactory (M7 en attente)

Pour le besoin courant, basculer sur mansart-jakarta-data directement.

HQL

JPQL (M7) ou JDQL (livré)

Mansart cible la spec, pas les extensions HQL propriétaires.

@Entity, @Id, @GeneratedValue, @Column

Identiques

Annotations JPA standard reconnues telles quelles.

@OneToMany, @ManyToMany, héritage

Hors scope v1

Reportés à mansart-persistence (M7).

Hibernate Reactive

mansart-jakarta-data + virtual threads

JDBC bloquant sous Loom — pas de Vert.x, pas de callback.

Listeners JPA (@PrePersist, @PostLoad)

Hors scope v1

Couvert par M7.

Critère / Criteria API

Hors scope v1

Couvert par M7.

Schema generation (hibernate.hbm2ddl)

Externe (Flyway / Liquibase recommandés)

Mansart ne gère pas les migrations DDL.

Cas d’usage moins fréquent, transposition similaire à Hibernate. Les annotations standard JPA 3.2 sont reconnues telles quelles ; les extensions propriétaires (@CustomConverter, @Cache(…​)) doivent être réécrites en équivalents standard ou différées à mansart-persistence (M7).

Depuis HikariCP (pool)

HikariCP mansart-pool Note

HikariDataSource

MansartDataSource

Implémente javax.sql.DataSource standard.

HikariConfig

PoolConfig builder

API similaire — jdbcUrl, username, password, maximumPoolSize → maxSize.

minimumIdle

minSize

Idem.

connectionTimeout

acquireTimeout

Idem.

idleTimeout

idleTimeout

Idem.

maxLifetime

maxLifetime

Idem.

leakDetectionThreshold

leakDetectionThreshold

Idem.

connectionTestQuery

validationQuery + validationMode=QUERY

Mansart privilégie Connection.isValid() (validationMode=IS_VALID) — JDBC standard, pas de SQL custom.

Métriques Micrometer / Prometheus

PoolMetrics (snapshot)

Bridge Micrometer dans le backlog mansart-pool.

Comparatif perf : voir lien:https://codeberg.org/Vidocq/mansart/src/branch/main/mansart-pool/BENCH.md[mansart-pool BENCH.md]. Mansart-pool est natif virtual threads et n’a pas le coût de pinning sous charge Loom.

Pièges connus

  • Pas de proxy d’entité — Mansart matérialise les entités directement. Le lazy loading n’est pas magique : @ManyToOne(fetch=LAZY) charge l’attribut au prochain accès via un getter intercepté par le bytecode généré APT (M5).

  • Pas d’auto-flush implicite — l’utilisateur appelle explicitement flush() ou termine la transaction. Différent de Hibernate qui flush au query.

  • Pas de scan d’entités runtime — l’APT enregistre les entités à la compilation. Ajouter une @Entity sans recompiler est une erreur classique en migration depuis Hibernate.

  • @OneToMany non supporté en v1 — modéliser explicitement via la @ManyToOne propriétaire et un findByOwner(…​) dans le repository de la cible.

Pas de migration nécessaire

Vidocq Runtime livre vidocq-runtime-mansart-h2-example qui montre une intégration neuve de bout en bout. Pour un nouveau projet, partir directement de cet exemple est souvent plus simple que de migrer un legacy.