Opérations persit merge etc personnalisées

Bonjour,

Je travaille actuellement sur un mapping assez délicat. Le schéma de base de donnée imposé par le client ne se prête pas du tout à un mapping hibernate pour une des entités. Par exemple, la table où l'entité doit être enregistrée dépend de la classe qui la contient. Et ce n'est qu'une des règles de gestion de la base de données qui ne correspond pas du tout à l'esprit Hibernate.

Je me demandais si il était possible de définir entièrement manuellement les opérations à effectuer sur l'entité en question. Par exemple quand Hibernate veut enregistrer l'entité en base, il appellerait à la place une fonction de rappel où je ferais moi-même les requêtes SQL.

Pour information, je connais les annotations @SQLInsert etc., mais elles ne sont pas suffisantes dans mon cas d'utilisation.

Merci d'avance.

Si c'est des tables séparées, pourquoi utiliser la même entité et pas des entités séparées?

Si c'est pour faire toutes les requêtes toi même, autant te passer d'hibernate, je ne vois pas ce que tu compte gagner à utiliser hibernate.

Si c'est des tables séparées, pourquoi utiliser la même entité et pas des entités séparées?
C'est le même concept, et ça devrait être une seule et même table. Le client en a décidé autrement. Côté Java, cette entité est gérée et générée par une multitude de processus métier. Je n'ai pas envie de faire une copie différente de ces processus pour chaque table ou l'entité peut être stockée. Le polymorphisme n'est pas une solution, car ces processus doivent pouvoir construire de nouvelles instances.

Si c'est pour faire toutes les requêtes toi même, autant te passer d'hibernate, je ne vois pas ce que tu compte gagner à utiliser hibernate.
J'ai plus de 60 autres entités qui ne posent aucun problème.

Est-ce que le choix de la table peut être fait uniquement à partir des données dans l'objet? Est-ce que secondarytables ne pourrait pas être abusé pour atteindre ton objectif, couplé à des propriétés dérivées? http://stackoverflow.com/questions/2...ax-persistance

Aussi, si la sb le supporte, une vue pourrait être une solution.

Aussi, il y a la solution de ne pas mapper cette table sur une entité, juste cette table si les autres fonctionnent. C'est pas top niveau architecture mais ça peut être isolé à bas niveau, via des pre/post contruct sur les entités en dépendant.

Je ne peux pas modifier la base de données elle-même, la raison pour laquelle j'ai ce problème est que le client a imposé un schéma inapproprié. Si je pouvais modifier la base de données, j'utiliserai juste une table pour cette entité.

Pour l'instant, j'ai juste créé une classe pour chacune des tables cibles, et elle a un mapping Hibernate. L'entité est marquée @Transient, et n'est qu'un masque qui délègue toutes ses fonctionnalités aux classes tables. Ie quand on appelle un setter sur l'entité, elle appelle en faite le setter de la classe correspondant à la table cible. Assez crade, mais c'est invisible vu de l'extérieur du package. Le problème est qu'il y a un tas de code à copier à chaque utilisation.