[(N)Hibernate ] ID's voor entities *

[Macros]

Stel je hebt de kans om een nieuwe applicatie plus database te ontwerpen en je besluit (N)Hibernate te gebruiken. Hoe definieer je dan de id's van je entiteiten?

Ik zie 3 mogelijkheden:
1) Je gebruikt autoincrement/sequences op database niveau, of in hibernate met een SequenceGenerator.
2) Je gebruikt een UUID generator bij object construction om meteen een id te genereren die uniek is. Die wordt pas gepersist als de entiteit wordt gepersist, maar die kan meteen voor equals() en hashcode() worden gebruikt. De kans op collisions is te klein om echt relevant te zijn.
3) Je gebruikt een sequence generator tijdens object construction. In Hibernate heb je de SequenceHiLoGenerator of je kan een eigen implementatie maken.

Nu kort de pros en cons voor alle 3 de mogelijkheden:
1) pros:

• simpel
• is efficient en snel
• alle id's zijn opeenvolgend en kunnen relatief klein zijn, int's of longs

cons:

• Je kan geen gebruik maken van het id voor equals() en hashcode() functies omdat het id null kan zijn

2) pros:

• simpel
• is snel

cons:

• Mogelijkheid tot collisions als er veel entiteiten worden gepersist
• ID moet in de database waarschijnlijk een string worden omdat databases vaak geen 128 numeric type hebben *
• ID's zijn niet makkelijk te onthouden of te gebruiken als je met de hand queries schrijft tijdens debugging, en zijn niet oplopend

* Je zou tijdens een persist een mogelijke collision af kunnen vangen en dan een nieuwe UUID te genereren. Dan moet je gebruik maken van entiteit listeners of iets dergelijks. Introduceerd wel wat extra complexiteit en can hashcodes invalideren, wat ook weer andere problemen kan introduceren.

3) pros:

• Geen van de nadelen van de andere 2 mogelijkheden

cons:

• complex kwa code
• kan extra vertraging optreden bij het creeeren van vele entiteiten
• er is een database connectie nodig bij het creeeren van entiteiten

Wat zijn jullie ideeen over deze mogelijkheden en wat zouden jullie doen als je het zo bekijkt? Misschien ben ik wel een 4de of een 5de mogelijkheid vergeten.

[Alarmnummer]

Als ik werk met een database die sequences ondersteund, dan gebruik ik die gewoon. Die kun je via Hibernate gewoon aanspreken mbv de juiste generator.

Optie 1 hoeft optie 3 dus niet uit te sluiten.

Hashcode en equals zijn in principe niet nodig:
binnen 1 sessie wil je sowieso niet meerdere object-instanties hebben van dezelfde entitieit.
Je zit alleen met die k*t proxies die hibernate soms maakt waardoor het weer in de soep kan lopen.

[ Voor 10% gewijzigd door Alarmnummer op 22-02-2008 13:51 ]

[whoami]

Ik snap niet waarom 'je id kan null zijn' bij optie 1 een con is ?
In de constructor van je object kan je je id toch een bepaalde waarde geven (-1, Int32.MinValue, whatever), en de 'unsaved-value' dinges van HIbernate gebruiken ?

[Macros]

Het is een con omdat je het dan niet in equals en hashcode functies kan gebruiken. Een vaste waarde geven is daarvoor natuurlijk geen optie. Omdat alle unsaved objects dan ineens equal zijn.

[EfBe]

Mja, non-discussie. In je DB of auto-number/sequences gebruiken of zelf PK values definieren. PK's zijn nooit null, dus die 'con' klopt niet.

[Alarmnummer]

EfBe schreef op vrijdag 22 februari 2008 @ 16:06:
Mja, non-discussie. In je DB of auto-number/sequences gebruiken of zelf PK values definieren. PK's zijn nooit null, dus die 'con' klopt niet.

Het probleem is dat er een periode is dat het object wel gemaakt is (en gebruikt kan worden) terwijl de primary key nog niet is gezet. Als die uiteindelijk een keer is gezet, dan komt het allemaal goed. Maar zo lang die nog niet is gezet, kun er door een wijziging in de id, de equals en hashcode (indien ze van die id gebruik maken) andere waarden opleveren (en dat is niet wenselijk).

[EfBe]

Alarmnummer schreef op vrijdag 22 februari 2008 @ 16:19:
[...]

Het probleem is dat er een periode is dat het object wel gemaakt is (en gebruikt kan worden) terwijl de primary key nog niet is gezet. Als die uiteindelijk een keer is gezet, dan komt het allemaal goed. Maar zo lang die nog niet is gezet, kun er door een wijziging in de id, de equals en hashcode (indien ze van die id gebruik maken) andere waarden opleveren (en dat is niet wenselijk).

Equals kan dat ondervangen: die kan kijken of de entity new is en de PK een identity field is. Ja? -> object compare. Nee? -> pk compare.
Bij hashcode is het wat lastiger, daar moet je een besluit nemen, dus altijd PK value, of dat je wisselt tussen object value en pk value.

Het punt is dat een entity class instance in-memory helemaal geen entity is, dat is hij pas wanneer deze is weggeschreven. na de insert krijg je de sequence value gewoon in je entity gezet. Althans, dat zou zo moeten zijn, geen idee hoe nhibernate dit oplost.

Zelf gaan lopen knoeien met sequences op de client zou ik nooit doen: 200 desktop installaties maken verbinding met dezelfde database en gaan aan het werk -> veel duplicate keys

[Macros]

Ik denk dat optie 1 ook de beste optie is, maar een aantal van je argumenten vind ik niet kloppen.

Een object die een mapping heeft met een database is een entity, het maakt niet uit of hij al gepersist is of niet. Als een entity wordt gedelete, is het object dan nog wel een entity of dan ineens niet meer?

Je kan niet 2 implementaties maken van equals, want dan kan de equals() ineens een andere waarde geven als je je entity persist. Bijv:

code:

O a = new O();
O b = em.find(1);
b.equals(a); => true
em.persist(b);
b.equals(a); => false

En je moet met 4 (of 3) mogelijkheden rekening houden in je equals.
1) Dat je zelf nog niet bent gepersist en de ander ook niet
2) Dat je zelf nog niet bent gepersist en de ander wel
3) Dat je zelf al wel bent gepersist, maar de ander niet
4) Dat je zelf al wel bent gepersist en de ander ook

[SPee]

2) pros:
simpel
is snel
cons:
Mogelijkheid tot collisions als er veel entiteiten worden gepersist
ID moet in de database waarschijnlijk een string worden omdat databases vaak geen 128 numeric type hebben *
ID's zijn niet makkelijk te onthouden of te gebruiken als je met de hand queries schrijft tijdens debugging, en zijn niet oplopend

Een UUID is niet bepaald snel.
Ik heb op mijn werk een applicatie in beheer, welke gebruik maakt van UUID voor de keys. Mede door die keys is het beheer op de database (en waarschijnlijk ook het joinen over meerdere tabellen) een stuk langzamer dan met makkelijkere ID's.

Wat is makkelijker om door te zoeken in je database?
Een CHAR(32) welke pas op de laatste karakter kan verschillen en hij dus bijna alle 32 tekens af moet lopen, of een oplopende INT, waarvan makkelijk te herkennen is of hij eerder of later is.

[RobIII]

SPee schreef op vrijdag 22 februari 2008 @ 17:28:
Wat is makkelijker om door te zoeken in je database?
Een CHAR(32) welke pas op de laatste karakter kan verschillen en hij dus bijna alle 32 tekens af moet lopen, of een oplopende INT, waarvan makkelijk te herkennen is of hij eerder of later is.

Een UUID is (usually) ook gewoon een int hoor; alleen is die 128 bits groot Dus ik zie niet waarom je dan door 32 chars zou moeten fietsen?

[ Voor 11% gewijzigd door RobIII op 22-02-2008 18:28 ]

[EfBe]

Macros schreef op vrijdag 22 februari 2008 @ 17:11:
Ik denk dat optie 1 ook de beste optie is, maar een aantal van je argumenten vind ik niet kloppen.

Een object die een mapping heeft met een database is een entity, het maakt niet uit of hij al gepersist is of niet. Als een entity wordt gedelete, is het object dan nog wel een entity of dan ineens niet meer?

Je hebt maar 1 application state. Jij verwart user state met application state. Stel ik heb 2 threads, 2 users en die gaan beide customer Tweakers BV aanmaken. Dan heb jij dus 2 keer een entity Tweakers BV van het type Customer? nee. 0. Totdat de persist plaatsvindt en er 1 overblijft.

Lees mn essay in Jimmy Nilsson's boek ADDDP of lees het hier:
http://weblogs.asp.net/fb...-is-the-Domain-Model.aspx

Je kan niet 2 implementaties maken van equals, want dan kan de equals() ineens een andere waarde geven als je je entity persist. Bijv:

code:

O a = new O();
O b = em.find(1);
b.equals(a); => true
em.persist(b);
b.equals(a); => false

Nee jouw code kan niet.
b.equals(a); => true
kan geen true geven in jouw code, want a is een lege bak. De entity is de DATA in de bak, niet de bak zelf. Als je de instance van de CLASS gelijk gaat stellen aan de data die er in zit dan ga je het schip in, die moet je los van elkaar zien.

En je moet met 4 (of 3) mogelijkheden rekening houden in je equals.
1) Dat je zelf nog niet bent gepersist en de ander ook niet
2) Dat je zelf nog niet bent gepersist en de ander wel
3) Dat je zelf al wel bent gepersist, maar de ander niet
4) Dat je zelf al wel bent gepersist en de ander ook

Nee hoor:
- indien een van beide new is: object compare
- anders pk compare.

Werkt prima.

[Macros]

SPee schreef op vrijdag 22 februari 2008 @ 17:28:
[...]

Een UUID is niet bepaald snel.
Ik heb op mijn werk een applicatie in beheer, welke gebruik maakt van UUID voor de keys. Mede door die keys is het beheer op de database (en waarschijnlijk ook het joinen over meerdere tabellen) een stuk langzamer dan met makkelijkere ID's.

Wat is makkelijker om door te zoeken in je database?
Een CHAR(32) welke pas op de laatste karakter kan verschillen en hij dus bijna alle 32 tekens af moet lopen, of een oplopende INT, waarvan makkelijk te herkennen is of hij eerder of later is.

Je primary key is altijd een index, dus dan maakt het niet uit hoe groot of breed hij is, een string index werkt net zo snel als een int index. Zolang je geen index erop hebt is het traag, maar een UUID zou niet trager moeten zijn dan welke andere kolom zonder index.

[Macros]

EfBe schreef op vrijdag 22 februari 2008 @ 19:20:
[...]

Je hebt maar 1 application state. Jij verwart user state met application state. Stel ik heb 2 threads, 2 users en die gaan beide customer Tweakers BV aanmaken. Dan heb jij dus 2 keer een entity Tweakers BV van het type Customer? nee. 0. Totdat de persist plaatsvindt en er 1 overblijft.

Lees mn essay in Jimmy Nilsson's boek ADDDP of lees het hier:
http://weblogs.asp.net/fb...-is-the-Domain-Model.aspx

Ik verwar helemaal niks. Als je 2 threads hebt die tegelijk een bepaalde entity maken, dan zal het zeer waarschijnlijk gaan om 2 aparte entiteiten en moeten dan 2 aparte rows in de database worden. Als dat niet zo is, dan zou je een unique exception moeten krijgen als je de 2de entity probeert te flushen naar de database omdat je nergens zegt dat je voor het flushen nog probeerd te mergen met een entity uit de database, en 2 threads impliceerd 2 aparte transacties.

Nee jouw code kan niet.
b.equals(a); => true
kan geen true geven in jouw code, want a is een lege bak. De entity is de DATA in de bak, niet de bak zelf. Als je de instance van de CLASS gelijk gaat stellen aan de data die er in zit dan ga je het schip in, die moet je los van elkaar zien.

De code kan of niet compleet zijn, of bepaalde properties krijgen al bepaarde waardes. Injection op het entity, of default properties, je kan helemaal niet weten of het echt een lege bak is.

[EfBe]

Macros schreef op zaterdag 23 februari 2008 @ 12:29:
[...]
Ik verwar helemaal niks. Als je 2 threads hebt die tegelijk een bepaalde entity maken, dan zal het zeer waarschijnlijk gaan om 2 aparte entiteiten en moeten dan 2 aparte rows in de database worden.

Nee, dat is onzin. JIJ beweert dat alles wat in-memory gecreeerd wordt al een entity is. Dat is onzin en ik geef een voorbeeld.

Als dat niet zo is, dan zou je een unique exception moeten krijgen als je de 2de entity probeert te flushen naar de database omdat je nergens zegt dat je voor het flushen nog probeerd te mergen met een entity uit de database, en 2 threads impliceerd 2 aparte transacties.

Dat is het punt helemaal niet! Jij beweert dat je IN MEMORY al 2 entities hebt, en die kunnen niet allebei gesaved worden, dat geef je gelukkig zelf ook aan. Maar, hoe kan dat nou? Je hebt eerst 2 entities, en nu blijkt er ineens dat er 1 niet kan bestaan? Wat als ik die users ieder op hun eigen desktop laat werken? Heb je uberhaupt wel het artikel gelezen dat ik gelinkt heb?

Het probleem met jouw aanpak is dat semantisch gezien je niet kunt verder werken met 'nieuwe' entities die niet zijn gesaved: ALLES valt om als die entities niet kunnen bestaan, zoals zou kunnen in mijn voorbeeld. Je kunt dan alles wat je met die entities hebt gedaan wegflikkeren. Dat is alleen logisch als je inziet dat er maar 1 entity instance is, en je in memory 2 mirrored copys hebt die jou in staat stellen om de eigenlijke instance te manipuleren.

[...]
De code kan of niet compleet zijn, of bepaalde properties krijgen al bepaarde waardes. Injection op het entity, of default properties, je kan helemaal niet weten of het echt een lege bak is.

Wat loop je nou eigenwijs te doen? Ik werk al meer dan 5 jaar full time aan een commerciele succesvolle O/R mapper, denk je nou werkelijk dat ik er geen fluit verstand van heb hoe het allemaal werkt?

Een entity heeft een ID, mapped op de PK van de target. Als jij die default zet met de ID van 1 in de CTor, dan klopt er iets niet, of wel? Dus je ctor call zet geen ID values die gelijk zijn aan een bestaande entity. Los daarvan is de object 'a' nieuw, dus kan alleen gelijk aan b zijn indien de ctor automatisch entity '1' fetched en dus niet 'nieuw' is.

Dit soort problemen zijn dingen die je goed moet oplossen in een o/r mapper anders loop je hoe dan ook tegen narigheid aan. En iedere o/r mapper doet dat ook, en wel op dezelfde manier zoals ik geschetst heb. Het ESSENTIELE onderdeel wat jij niet begrijpt is dat in-memory er niet toe doet: een entity instance is niet gelijk aan een entity class instance en wat random data in een object is nog geen entity instance.

Lees dat artikel maar, daar leg ik het uit hoe het zit en daarna snap je wat ik bedoelde. Hoeft natuurlijk niet, bespaar je wat tijd enzo, het nadeel is alleen dat jij een vraag had en kennelijk nog geen antwoord, of beter: je wilt geen antwoord horen wat je niet zelf bedacht hebt. Tja.

[ Voor 5% gewijzigd door EfBe op 23-02-2008 13:22 ]

[Macros]

Kijk, zolang we beiden een andere definitie van het woord 'entity' gebruiken kunnen we lullen wat we willen maar we komen er toch niet uit.

[EfBe]

Macros schreef op zaterdag 23 februari 2008 @ 13:38:
Kijk, zolang we beiden een andere definitie van het woord 'entity' gebruiken kunnen we lullen wat we willen maar we komen er toch niet uit.

Er is maar 1 definitie, volgens mij: die van P Chen. Ironisch gezien is 'entity' ook een definitie op zich Je creeert een entity instantie, de data. Die ken je semantische waarde toe (zodat "1, 1, "lalala BV", NULL" een klant voorstelt en niet een rijtje random data) door het type entity van de instantie daaraan te koppelen. maar die data zit ergens IN. Dat is een container, niet de instance van de entity zelf, want die zit daarin.

het cruciale punt is 'semantische waarde'. Je kunt in-memory wel een container creeeren en daar wat random data in kegelen en dan roepen "Dit is mn customer" maar dat zegt niets. De applicatie an sig heeft state en daarbinnen wordt die nieuwe entity instance geplaatst, pas dan is de entity instance ook daadwerkelijk een entity instance en niet een rijtje random data. Pas vanaf dat punt kun je ermee werken in de context (!) van de applicatie. Zolang je niet zorgt dat de entity instance deel uit maakt van de application state, kun jij niets zeggen over dingen van die application state die kennelijk gebaseerd zijn op iets wat daar niet deel van uitmaakt, bv verwijzen naar een entity instance die erbuiten valt (want die zit nog in memory).

Als je zo je probleem oplost is je initiele vraag ook zo beantwoordt. Ga je doorrommelen met het verwarren van user- en application state en wil je per-se in-memory entity objects met data zien als volwaardige entity instances, dan wordt het antwoord op jouw initiele vraag erg lastig. Maar vergeet niet: dat roep je zelf over je af. Het probleem is heel simpel, en het antwoord dus ook.

[Macros]

Ik vind de definitie die jij geeft voor een entity niet fijn. Voornamelijk omdat hij naar mijn mening niet waterdicht gedefinieerd is. Je zegt dat het pas een entity is als hij echt als een row in de database bestaat, maar wanneer is dat?

1) je instantieert een object waarvan de class op een table in de database is gemapped (ik vind het een entity maar kan nu nog wel meegaan met het idee dat het het niet is, jij niet)
2) je registreert het object bij je entitymanager (ik vind het nu zeker een entity, jij nog steeds niet)
3) je koppelt bestaande entities met deze entity, bijvoorbeeld door referenties naar dit nieuw object in die andere entities te maken (ik vind het nu zeker een entity, jij nog steeds niet)
4) je flushed de state van je nieuwe entities en de gemodificeerde entiteiten naar de database (jij vind het nu een entity, ik ook)
5) een exception vindt plaats, je transaction wordt gerolled back, de objecten (de entities?) bestaan nog in memory, maar niet meer in de database (nu is het voor jou geen entity meer, ik nog wel)

Nog een reden waarom ik niet van jouw definitie hou is van lange (extended) transactions, die ondermeer door Hibernate worden ondersteund. Je hebt een lang proces, en pas aan het einde wil je het resultaat committen. In alle tussenstappen werk je met entiteiten die wel of geen id in de database hebben, depending op de manier dat je id's toekent. De gebruiker die bezig is met die entiteiten in zijn proces vind dat de data waar hij mee werkt zeker wel tot de application state hoort. Maar jij vind zolang het niet naar de database is gecommit nog niet bij de application state hoort. Mijn gevoel zegt dat het dat wel is, maar jouw definitie niet, dus verwerp ik jouw definitie en blijf ik bij mijn definitie. Dan kan je wel verwijzen naar een heel verhaal (van ook je eigen hand blijkbaar, wat ook niet zo lekker is geschreven naar mijn mening, maar daar zal ik niet op ingaan) maar zonder argumenten en alleen maar autoritair gedrag.

Ik ben het meer eens met Alarmnummer, en ook al is hij soms ook een beetje bot, hij heeft tenminste zinnige argumenten.

Zolang je in 2 verschillende threads/transacties, 2 (pre)entities maakt, die 2 verschillende geheugen addressen zijn in je heap, maar wel naar dezelfde entiteit in de database gaan verwijzen, dan heb je een probleem en kan ik me niet voorstellen dat die 2 eigenlijk dezelfde entiteit zouden zijn. Beide kunnen dan ook niet gecommit worden naar de database. Maar dat moet je niet afdwingen met primary keys, maar met uniqueness van bepaalde gegevens in de data.

[EfBe]

Nou dan los je het toch lekker op jouw manier op, toch? Heb je nog steeds je originele vraag die een antwoord wil.

Dat jij vindt dat ik ongelijk heb, dat is jouw mening. Dat ik geen argumenten heb en alarmnummer wel, haha, tja...wellicht moet je zijn oplossing dan maar gebruiken. Niet gaan emmeren dat het later misloopt. Overigens staat dat artikel niet voor niks in Jimmy's boek. Dat jij het flut vindt, ook prima, maar je maakt jezelf dan wel wat ongeloofwaardig.

Overigens hebben langlopende transactions er geen moer mee te maken, de realiteit verandert dan niet ineens... Misschien eens opzoeken hoe databases omgaan met transactional data en isolation en wanneer data valide is voor de rest?

[ Voor 53% gewijzigd door EfBe op 23-02-2008 18:19 ]

[Macros]

Ja, ik zal je wel geloven vanwege je drogreden...; als iemand het in een boek heeft geschreven moet het wel waar zijn.
Transacties hebben er wel mee te maken, want dat was 1 van mijn argumenten waarom ik niet met jouw (jullie) definitie van entiteiten wil werken, dat je daar niet op in gaat maakt me niet. En je kan zelf ook niet lezen, want we kiezen uiteindelijk voor dezelfde oplossing, alleen ik was het niet eens met je beargumentatie van die redenen. Maar ja, who am I to question the self proclaimed god of computing?

[EfBe]

Macros schreef op zaterdag 23 februari 2008 @ 18:49:
Ja, ik zal je wel geloven vanwege je drogreden...; als iemand het in een boek heeft geschreven moet het wel waar zijn.

jij kent Jimmy Nilsson niet? Drogreden? tja, it's your loss.

Transacties hebben er wel mee te maken, want dat was 1 van mijn argumenten waarom ik niet met jouw (jullie) definitie van entiteiten wil werken, dat je daar niet op in gaat maakt me niet.

het is niet mijn definitie, het is DE definitie. Ik refereerde er alleen maar naar.

En je kan zelf ook niet lezen, want we kiezen uiteindelijk voor dezelfde oplossing, alleen ik was het niet eens met je beargumentatie van die redenen. Maar ja, who am I to question the self proclaimed god of computing?

Aggossie... waar zeg ik dat ik dat van mezelf vind? Ik erger me er alleen stierlijk aan dat iemand eerst een vraag stelt, dan een antwoord krijgt van mij en dan het antwoord niet wil horen (dat is nog tot daar aan toe) maar wel met de reden dat ik er eigenlijk niets van begrijp. Iemand die vragen stelt snapt er m.i. altijd minder van dan degene die de vraag beantwoordt, of niet? Maar goed, veel succes nog met het zoeken naar je antwoord.