[Java/Hibernate] Criteria voor "referenced by"

[Swinnio]

Wellicht een wat verwarrende topictitel maar ik zal het proberen uit te leggen. Ik heb twee tabellen. De eerste representeert een soort van tijdstip en heeft een one-to-many relatie met een tabel met metingen. Er zijn namelijk meerdere metingen voor een bepaald tijdstip. De tabel met metingen heeft dus een FK naar de Tijdstip-tabel. So far, so good. Daarnaast heeft de Tijdstip tabel ook een verwijzing naar de Meting tabel om aan te geven dat een meting een maximum waarde voor dat tijdstip is. Uiteindelijk moet er voor elk tijdstip (dus elke rij in de Tijdstip tabel) een maximum waarde zijn, en dus een verwijzing naar een Meting rij.
Nu zul je je wellicht afvragen waarom er voor deze vreemde structuur gekozen is en waarom maxima niet m.b.v. queries worden bepaald, maar dat is nu helaas niet het probleem
Het probleem is dat ik m.b.v. Hibernate Criteria API alle instanties uit de Meting tabel wil halen, die:
1) in een bepaalde periode zijn gedaan. Dit is makkelijk: de Tijdstip tabel heeft een veld waarop ik een BETWEEN kan doen.
2) die voor hun tijdstip het maximum waren. Ofwel, waar naar verwezen wordt door de "maximum_fk" column uit de Tijdstip tabel. Dit zijn uiteraard alleen tijdstippen die tevens aan 1) voldoen.

Omdat ik metingen wil ophalen, maak ik een criteria aan voor die class. Maar nu moet ik dus via de property "tijdstip" van de Meting tabel bij het bebehorende tijdstip komen voor 1) en vervolgens eisen dat ik alleen Metingen ophaal waarvoor 2) geldt. Dat laatste krijg ik met geen mogelijkheid voor elkaar.
Ben er van overtuigd dat het puur een denkfout m.b.t. het gebruik van Criteria is, want in plain SQL zou dit niet zo'n probleem moeten zijn. Alleen is de hele applicatie met Criteria opgezet, dus daar zou ik voor dit geval niet van af willen wijken.

[ Voor 2% gewijzigd door Swinnio op 29-10-2008 09:00 . Reden: verduidelijking ]

[Janoz]

Nu zul je je wellicht afvragen waarom er voor deze vreemde structuur gekozen is en waarom maxima niet m.b.v. queries worden bepaald, maar dat is nu helaas niet het probleem

Ik vermoed dat daar de eerste denkfout zit.

Verder is mijn ervaring dat Criteria erg handig werken, totdat de queries ingewikkeld worden. Het is wel te doen, maar op een gegeven moment kom je op een omslag punt waarbij gewoon een hql string beter te begrijpen en dus ook beter te onderhouden is.

Ik weet niet hoe jullie applicatie verder in elkaar steekt, maar wanneer je binnen 1 dao methode hql ipv Criteria gebruikt lijkt dit me niet voor grote problemen zorgen. (Anders wordt het natuurlijk wanner er helemaal geen scheiding aangebracht is tussen de verschillende applicatie lagen, maar in dat geval is je probleem eigenlijk nog veel groter).

[Swinnio]

Janoz schreef op woensdag 29 oktober 2008 @ 11:12:
[...]

Ik vermoed dat daar de eerste denkfout zit.

Ja, maar dat is een denkfout die niet door mij is gemaakt :-) Die oplossen is dus meer werken dan zelf een werkende query te bouwen.

Verder is mijn ervaring dat Criteria erg handig werken, totdat de queries ingewikkeld worden. Het is wel te doen, maar op een gegeven moment kom je op een omslag punt waarbij gewoon een hql string beter te begrijpen en dus ook beter te onderhouden is.

Ik weet niet hoe jullie applicatie verder in elkaar steekt, maar wanneer je binnen 1 dao methode hql ipv Criteria gebruikt lijkt dit me niet voor grote problemen zorgen. (Anders wordt het natuurlijk wanner er helemaal geen scheiding aangebracht is tussen de verschillende applicatie lagen, maar in dat geval is je probleem eigenlijk nog veel groter).

In principe is het binnen de DAO inderdaad geen probleem hql te gebruiken i.p.v. Criteria. Maar tot nu toe is het me iedere keer gelukt een Criteria variant te bedenken en ik wil daar eigenlijk niet zonder meer vanaf stappen omdat de hql query net even makkelijker op te schrijven is...

[Janoz]

Het is niet alleen een kwestie van makkelijker opschrijven. Toevallig had ik laatst bijna hetzelfde. Voor een bepaalde management rapportage was er een best ingewikkelde query. Hij begon redelijk recht toe recht aan, maar doordat er allemaal uitzonderingsgevalletjes bij kwamen was hij op een gegeven moment behoorlijk gegroeid.

Je kunt dan documenteren wat je wilt, maar wanneer het opbouwen van de criteria over meer dan een pagina verspreid is wordt het nauwelijks meer te onderhouden. Dat bleek, want toen een collega van mij een RFC op dat stukje code kreeg heeft hij het maar herschreven naar een hql query omdat hij geen duidelijk beeld meer kreeg van de huidige implementatie. (Herschrijven was goed te doen aangezien er wel uitgebreide unittests bij zaten waardoor de huidige werking gegarandeerd kon blijven)

[Swinnio]

Janoz schreef op woensdag 29 oktober 2008 @ 11:26:
Het is niet alleen een kwestie van makkelijker opschrijven. Toevallig had ik laatst bijna hetzelfde. Voor een bepaalde management rapportage was er een best ingewikkelde query. Hij begon redelijk recht toe recht aan, maar doordat er allemaal uitzonderingsgevalletjes bij kwamen was hij op een gegeven moment behoorlijk gegroeid.

Je kunt dan documenteren wat je wilt, maar wanneer het opbouwen van de criteria over meer dan een pagina verspreid is wordt het nauwelijks meer te onderhouden. Dat bleek, want toen een collega van mij een RFC op dat stukje code kreeg heeft hij het maar herschreven naar een hql query omdat hij geen duidelijk beeld meer kreeg van de huidige implementatie. (Herschrijven was goed te doen aangezien er wel uitgebreide unittests bij zaten waardoor de huidige werking gegarandeerd kon blijven)

Ja, je hebt op zich wel een punt. Het zal in lastige gevallen zeker zo zijn dat een HQL query makkelijker te doorgronden is. Toch heb ik het inmiddels wel voor elkaar gekregen om bovenstaand geval op te lossen met een Criteria die in totaal 4 regels code beslaat.
FWIW: de denkfout was dat ik query wilde opbouwen uitgaande van de Meting tabel. De goede oplossing was echter te constraints op de Tijdstip tabel te zetten en vervolgens d.m.v. een projection (op de property voor de maximale waarde) de bijbehorende rijen in de Meting tabel op te halen.