Hibernate HQL au SQL de base (pas de jointures)

Je travaille sur un projet avec Hibernate et nous devons remplacer Hibernate par du "persistant fait maison". L'idée est que le projet est assez grand, et nous avons beaucoup de requêtes HQL. Le problème est avec les requêtes commeHibernate HQL au SQL de base (pas de jointures)

select a,b from table1, table2 on t1.table1=t2.table2

Fondamentalement, tous les joints ne sont pas pris en charge par nos affaires « fait main persistance ».

Ce que je aurais besoin, est d'être en mesure de faire une sorte de transcodeur, qui prendra comme entrée les requêtes HQL et SQL sortie un peu, mais SQL sans joint

J'espère que vous avez l'idée. Ma couche de persistance ne prend pas en charge les jointures.

Est-ce que quelqu'un a une idée de quelque chose comme ça? Un cadre, ou quelque chose?

Source

2010-05-19 CC.

Sans vouloir offenser, mais jeter un ORM établi pour un ORM réinvente sérieusement la roue. Vous seriez mieux servi en apprenant plus sur l'optimisation de vos requêtes HQL afin qu'ils produisent le meilleur SQL possible. – roufamatic

Je n'ai pas demandé comment améliorer le HQL. Ce n'est pas l'idée. Je ne peux pas expliquer plus sur pourquoi nous changeons hibernate. Nous avons quelques avantages à changer d'hibernation. –

"établi" ne signifie pas complet ou non-buggé. Hibernate a quelques limitations sérieuses dans certains domaines, qui n'ont pas été traitées dans 5 ans. –

Vous ne pouvez pas faire ce que HQL est en train de faire sans JOIN. Ce que vous pouvez faire est de mettre en œuvre les jointures dans une vue, puis utiliser vos éléments d'origine pour interroger la vue. Cela vous isole de l'implémentation des jointures. La seule façon d'obtenir ce que vous voulez sans JOIN quelque part est d'interroger chaque table, puis de fusionner les résultats dans votre code.

Source

2010-05-19 21:27:34

oui, c'est une idée, mais j'ai plus de 100 requêtes, donc il n'est pas possible de créer des vues pour chaque jointure que j'ai. J'aurais besoin d'un traducteur générique. Je pense à quelque chose comme comment Hibernate traduit le HQL, mais quand il fait les jointures, pour changer en quelque sorte. C'est compliqué ce dont j'ai besoin, mais j'en ai vraiment besoin. –

JOINS fait exactement ce qu'ils disent, ils rejoignent les données de deux tables ou plus ensemble, il n'y a pas d'autre moyen que d'interroger chaque table et de les fusionner ensemble dans votre code, c'est vraiment une mauvaise approche. Home cultivé signifie juste ce fait maison, code fait à la main, seulement à partir des morceaux les plus frais. Apprenez à coder. –

Quand j'ai fait maison triste, je voulais dire que nous avons acheté ceci, pour certains avantages que hiberner n'a pas, et si beaucoup plus important que les jointures. –

Il semble que vous ne voulez pas vous débarrasser des jointures mais les exprimer dans le très vieux formulaire SQL89. De toute façon, c'est toujours une jointure.

SQL92 Syntaxe:

SELECT FROM TABLE1 T1 
JOIN TABLE2 ON T1.ID = T2.ID;

SQL89 Syntaxe:

SELECT FROM TABLE1 T1, TABLE2 T2 
WHERE T1.ID = T2.ID;

Je suis tout surpris que coûterait l'argent ces jours-ci ne manquera pas de soutenir une presque deux décennies syntaxe.

Source

2011-05-21 15:11:07 Brian

Hibernate HQL au SQL de base (pas de jointures)

Répondre

Questions connexes