[NHibernate] mapping attributes wel zo verstandig?

[DrDelete]

Ik kwam toevallig wat codesnippets tegen in een boek waar NHibernate mapping attributes gebruikt werden.

Nu heb ik zelf in het verleden alleen NHibernate mapping xml files gebruikt.

Persoonlijk zou ik zelf geen mappings in code willen hebben maar juist in externe mapping files vanwege onderhoudbaarheid.

Hoe denken jullie hierover?

[RobIII]

quote: http://www.hibernate.org/...l/mapping-attributes.html

With NHibernate.Mapping.Attributes, you can use .NET attributes to decorate your entities and these attributes will be used to generate these mapping .hbm.xml (as files or streams). So you will no longer have to bother with these nasty xml files .

What's the difference dan?

[Verwijderd]

DrDelete schreef op woensdag 30 juli 2008 @ 09:25:
Hoe denken jullie hierover?

Als je inderdaad de purist uit wil hangen en dus alle verantwoordelijkheden uit elkaar houdt dan ga je voor de xml file.

Maar dan even realistisch aan het werk. Who cares dat je het niet correct gescheiden hebt. Het is niet dat je domein objecten herbruikbaar zijn, ze horen bij het project. Dus het is simpelweg verdomde handig om dit aan te geven in je classes.

[EfBe]

Verwijderd schreef op woensdag 30 juli 2008 @ 09:43:
[...]
Als je inderdaad de purist uit wil hangen en dus alle verantwoordelijkheden uit elkaar houdt dan ga je voor de xml file.

Maar dan even realistisch aan het werk. Who cares dat je het niet correct gescheiden hebt. Het is niet dat je domein objecten herbruikbaar zijn, ze horen bij het project. Dus het is simpelweg verdomde handig om dit aan te geven in je classes.

Totdat je 2 databases wilt gaan supporten ipv die ene die je initieel supportte. dan ineens is het veel werk om die attributes eraf te halen.

Gavin King, de maker/bedenker van Hibernate vind attributes (annotations in java) het beste dat ooit bedacht is. Het rare is echter dat in de O/R mapper wereld al lang een consensus is bereikt omtrent of attributes/annotations nu wel of niet goed zijn voor mappings: ze zijn niet goed voor mappings, omdat ze meta-data waar je normaliter niets mee te maken hebt in je code, mergen met je code. Is de code gegenereerd vanuit meta-data, dan is het feitelijk een projectie waar je niet aankomt. Is het handgeschreven code, zoals nhibernate domain classes, dan heb je wel een probleem, want de bron van je code is de code zelf, en daar meta-data in prakken... waar alleen de o/r mapper kernel mee te maken heeft... dat is niet echt onderhoudbaar.

[Verwijderd]

EfBe schreef op woensdag 30 juli 2008 @ 10:41:
Totdat je 2 databases wilt gaan supporten ipv die ene die je initieel supportte. dan ineens is het veel werk om die attributes eraf te halen.

Echt uit de categorie: lekker belangrijk. De kans hierop is ongeveer gelijk aan nul.
Maar misschien heeft iemand anders nog andere onwerkelijke uitzonderingen.

EfBe schreef op woensdag 30 juli 2008 @ 10:41:
[...]want de bron van je code is de code zelf, en daar meta-data in prakken... waar alleen de o/r mapper kernel mee te maken heeft... dat is niet echt onderhoudbaar.

Onzin argument. Je vind je mapping sneller als het in de code zit en dus makkelijker onderhoudbaar.

Zo nu ben ik wel weer klaar met de vooral krachttermen. Overigens gebruik ik zelf aparte meta data bestanden maar dat is vooral een puristische overweging

[ Voor 39% gewijzigd door Verwijderd op 30-07-2008 10:50 ]

[EfBe]

Verwijderd schreef op woensdag 30 juli 2008 @ 10:45:
[...]
Echt uit de categorie: lekker belangrijk. De kans hierop is ongeveer gelijk aan nul.
Maar misschien heeft iemand anders nog andere onwerkelijke uitzonderingen.

Gelijk aan 0? Omdat jij met je wereldbeeld alles gezien hebt? multi-db projects komen zeer zeker voor, en veel meer dan jij denkt. (en voordat jij gaat beweren dat ik het niet weet, veel van onze klanten gebruiken multi-db om hun product te supporten op meerrdere db types, bv sqlserver en oracle. )

[...]
Onzin argument. Je vind je mapping sneller als het in de code zit en dus makkelijker onderhoudbaar.

Dat was totaal mijn punt niet. Maar ik heb hier verder geen zin in, je wilt alleen lekker zeiken, toedeloe!

[whoami]

EfBe schreef op woensdag 30 juli 2008 @ 10:41:
[...]

Totdat je 2 databases wilt gaan supporten ipv die ene die je initieel supportte. dan ineens is het veel werk om die attributes eraf te halen.

Nu ben ik ook geen voorstander van attributes om je mappings te definieren, maar, als je meerdere databases wilt supporten, dan ga je er toch voor zorgen dat je tabellen, kolommen, etc... zowel in DBMS X als in DBMS Y dezelfde naam hebben, toch ?
Maw: ik zie niet in waarom dit een probleem is om je mappings via attributes te doen ?

Ik ben geen voorstander van mappings mbt attributes omdat ik die mapping gewoon niet wil zien als ik m'n code bekijk, en, als ik die mapping wel wil zien, dan weet ik dat ik gewoon file blabla.hbm.xml moet bekijken, en daar heb ik de volledige mapping voor class blabla in één oogopslag. Ik kan me voorstellen dat dit wel eens anders kan zijn als je attributes gebruikt.

[DrDelete]

whoami schreef op donderdag 31 juli 2008 @ 09:52:
[...]
Ik ben geen voorstander van mappings mbt attributes omdat ik die mapping gewoon niet wil zien als ik m'n code bekijk, en, als ik die mapping wel wil zien, dan weet ik dat ik gewoon file blabla.hbm.xml moet bekijken, en daar heb ik de volledige mapping voor class blabla in één oogopslag. Ik kan me voorstellen dat dit wel eens anders kan zijn als je attributes gebruikt.

daar ben ik het volledig mee eens.

daarnaast is het ombuigen naar een eventueel andere db beter te doen via de xml files, je houdt zo d code schoon van db specifieke mappings

[Verwijderd]

EfBe schreef op donderdag 31 juli 2008 @ 09:32:
Gelijk aan 0? Omdat jij met je wereldbeeld alles gezien hebt? multi-db projects komen zeer zeker voor, en veel meer dan jij denkt. (en voordat jij gaat beweren dat ik het niet weet, veel van onze klanten gebruiken multi-db om hun product te supporten op meerrdere db types, bv sqlserver en oracle. )

Nee simpelweg omdat het er zoals gewoonlijk niet om gaat wat je eigen ervaring is. Het gaat erom dat je meestal toch wel van te voren weet of je een domein model in verschillende datastores hebt. De uitzondering argumenten zijn dus niet ze gek veel waard. Zeker niet omdat je altijd nog je metadata met een tool uit je domein model kunt halen. Het is dus niet zo dat je je vast pint.

EfBe schreef op donderdag 31 juli 2008 @ 09:32:
Dat was totaal mijn punt niet.

Wees dan veel duidelijker wat je punt is, want de enige die je maakt heb ik op gereageerd. Je punt is onderhoudbaarheid. Een van de facetten van onderhoudbare code is begrijpelijke code. Mapping bestandje hier, stukje code daar is voor nieuwe/andere mensen niet makkelijk om in te stappen. Vrij duidelijk als het bij de code staat.

[Niemand_Anders]

Verwijderd schreef op donderdag 31 juli 2008 @ 09:55:
Wees dan veel duidelijker wat je punt is, want de enige die je maakt heb ik op gereageerd. Je punt is onderhoudbaarheid. Een van de facetten van onderhoudbare code is begrijpelijke code. Mapping bestandje hier, stukje code daar is voor nieuwe/andere mensen niet makkelijk om in te stappen. Vrij duidelijk als het bij de code staat.

Maar de meeste developers hoeven toch helemaal niet te weten uit welke table/column een waarde komt. Zij werken slechts met de data entity en het zal hun een worst zijn waar de informatie vandaan komt.

De paar developers welke verantwoordelijk zijn voor de DAL weten echt wel de hbm.xml bestanden te vinden. Wij hebben namelijk ook een aantal WCF services welke de data aanleveren (desktop applicaties) omdat deze geen directe toegang tot de database hebben. De data entities zijn gedefineerd in de Infrastructure.Interfaces assembly. En in mijn opinie behoort daar geen database informatie thuis.

Elke database server waarvoor wij support hebben heeft een zijn eigen DAL. In die DAL bevind zich de mapping voor de specifieke database. In ons geval zouden wij dat de data entities in de DAL moeten overerven zodat wij dan daarop de attributen kunnen zetten. Dan werkt een hbm.xml bestand toch een stuk fijner.

Bij een aantal mini websites maken wij wel gebruik van attributen, maar dan degene van Active Record (Windsor Castle). Bij een proof-of-concept website op basis van asp.net mvc gebruiken wij linq 2 sql als model.

[wasigh]

EfBe schreef op woensdag 30 juli 2008 @ 10:41:
[...]

Totdat je 2 databases wilt gaan supporten ipv die ene die je initieel supportte. dan ineens is het veel werk om die attributes eraf te halen.

Gavin King, de maker/bedenker van Hibernate vind attributes (annotations in java) het beste dat ooit bedacht is. Het rare is echter dat in de O/R mapper wereld al lang een consensus is bereikt omtrent of attributes/annotations nu wel of niet goed zijn voor mappings: ze zijn niet goed voor mappings, omdat ze meta-data waar je normaliter niets mee te maken hebt in je code, mergen met je code. Is de code gegenereerd vanuit meta-data, dan is het feitelijk een projectie waar je niet aankomt. Is het handgeschreven code, zoals nhibernate domain classes, dan heb je wel een probleem, want de bron van je code is de code zelf, en daar meta-data in prakken... waar alleen de o/r mapper kernel mee te maken heeft... dat is niet echt onderhoudbaar.

Op dit moment ben ik bezig met een C# desktopapplicatie en een eigen O/R mapper gebaseerd op het model wat ik afgekeken heb van CakePHP. Mijn overweging is juist om attributes op te nemen in de code. In mijn ogen is metadata nutteloos zonder een direct verband met de data waar het om gaat. Daarbij word ik helemaal gestoord dat wanneer ik code op 1 plek wijzig ik dan rekening moet houden met andere plekken waar ik ook code moet werken. Dat is voor mij niet onderhoudbaar..

Daarom ben ik heel benieuwd waarom attributes afgeschreven zijn door de O/R mappings wereld. Ik krijg de indruk dat dat komt omdat er in de metadata ook configuratie settings worden opgenomen (database namen etc). En configuratie settings wil je natuurlijk kunnen wijzigen. Maar op het moment dat een relatie tussen 2 entiteiten verandert dan zul je toch zowel je code als je mapping aan moeten passen? Maar ik ben niet al teveel bekend in die wereld. Misschien kun jij daar je licht over laten schijnen?

[Niemand_Anders]

Maar hoe kunnen jouw data entities wijzigen zonder dat de database zelf wijzigd? Daarbij kun je wel een extra property aanmaken, maar als deze vervolgens nergens wordt gebruikt is deze nutteloos.

En wat als jouw desktop programma ineens op een Asus Eee netbook moet draaien? UMTS verbindingen met een vast ip zijn zeldzaam. Op dat moment zal de applicatie dan gebruik moeten gaan maken van bijvoorbeeld webservice proxies want je gaat de database server niet voor de gehele wereld openzetten (dwz ik hoop van niet).

Attributen zijn interessant in kleinere projecten waarbij de verschillende applicatie lagen in elkaar oversmelten. Een windows form praat dan al snel zelf tegen de data laag. Echte business objecten zijn dan vaak niet aanwezig. Linq 2 sql speelt hier al op in. Het Ado Entity framework moet het grote broertje daarvan gaan worden, maar moet dan wel de concurrentie aan met o/r mappers welke hun bestaansrecht allang hebben bewezen.

En trouwens op het moment dat een relatie wijzigd, dan zul je ipv een mapping bestand nu een aantal attributen moeten gaan veranderen. Bedenk de attributen door NHibernate zelf worden gebruikt om 'dynamisch' de mapping te maken. Echter NHibernate analyseert dan wel direct alle mappings en deze worden ook allemaal ingeladen. Afhankelijk van het aantal data entities kan de startup tijd dan onnodig toenemen. Persoonlijk maak ik altijd gebruik van lazy initialisatie (load on demand). Uiteindelijk als alle mappings zijn ingeladen heeft het even veel tijd gekost, maar omdat de mappings pas worden ingeladen om het moment dat ze nodig zijn, verspreid je de initialisatie load.

[DrDelete]

wasigh schreef op donderdag 31 juli 2008 @ 12:42:
[...]

Op dit moment ben ik bezig met een C# desktopapplicatie en een eigen O/R mapper gebaseerd op het model wat ik afgekeken heb van CakePHP. Mijn overweging is juist om attributes op te nemen in de code. In mijn ogen is metadata nutteloos zonder een direct verband met de data waar het om gaat. Daarbij word ik helemaal gestoord dat wanneer ik code op 1 plek wijzig ik dan rekening moet houden met andere plekken waar ik ook code moet werken. Dat is voor mij niet onderhoudbaar..

Daarom ben ik heel benieuwd waarom attributes afgeschreven zijn door de O/R mappings wereld. Ik krijg de indruk dat dat komt omdat er in de metadata ook configuratie settings worden opgenomen (database namen etc). En configuratie settings wil je natuurlijk kunnen wijzigen. Maar op het moment dat een relatie tussen 2 entiteiten verandert dan zul je toch zowel je code als je mapping aan moeten passen? Maar ik ben niet al teveel bekend in die wereld. Misschien kun jij daar je licht over laten schijnen?

Code & mapping moeten worden aangepast, echter... als ik een entity zuiver houdt zonder mapping in code kan ik daarna kiezen door welke tooling ik laat mappen. Als ik attributes gebruik ben ik gebonden aan een bepaalde O/R mapper vanwege de reference/namespace die ik moet includen. Als het in een aparte xml file staat is het ook wel gebonden aan een bepaald type O/R mapper maar staat het los van de source code.

[EfBe]

wasigh schreef op donderdag 31 juli 2008 @ 12:42:
[...]

Op dit moment ben ik bezig met een C# desktopapplicatie en een eigen O/R mapper gebaseerd op het model wat ik afgekeken heb van CakePHP. Mijn overweging is juist om attributes op te nemen in de code. In mijn ogen is metadata nutteloos zonder een direct verband met de data waar het om gaat. Daarbij word ik helemaal gestoord dat wanneer ik code op 1 plek wijzig ik dan rekening moet houden met andere plekken waar ik ook code moet werken. Dat is voor mij niet onderhoudbaar..

Dat is het gevolg van het feit dat je niet met een abstracte entity definitie werkt waarje de class en table vanaf leidt (aangezien ze beide projecties zijn van die abstracte entity definitie) maar dat je met de projecties zit te werken en daar wijzigingen in aanbrengt. Dus je wijzigt class A, die is de projectie van entity A' op C#, en dus moet je die eerst reverse engineeren naar A', dan de projectie van die wijzigingen maken op een relationeel model zodat je over hetzelfde praat.

Daarom ben ik heel benieuwd waarom attributes afgeschreven zijn door de O/R mappings wereld. Ik krijg de indruk dat dat komt omdat er in de metadata ook configuratie settings worden opgenomen (database namen etc). En configuratie settings wil je natuurlijk kunnen wijzigen. Maar op het moment dat een relatie tussen 2 entiteiten verandert dan zul je toch zowel je code als je mapping aan moeten passen? Maar ik ben niet al teveel bekend in die wereld. Misschien kun jij daar je licht over laten schijnen?

De meeste attribute based mappings hebben target DB specifieke informatie in zich, zoals field length, identity sequences, target types, etc. Dit is funest voor het hergebruiken van domain classes op andere databases. Men kan wel denken dat attribute based mappings alleen field names bevatten maar dat is onzin, daarmee kom je er niet. Je hebt hoe dan ook DB specifieke meta-data nodig en als je dat niet in mappings kwijt kunt, moet dat worden opgehaald at runtime.

En dan heb ik het nog niet eens over het gebrek aan type ABC op database X terwijl deze beschikbaar is op database Y (bit/bool bv). Je hebt dan conversie mappings nodig voor bv Oracle, maar niet voor SqlServer. Je domaincode blijft hetzelfde. DAT zijn problemen waar je tegenaanloopt bij multi-db, en ik erger me echt mateloos aan het gebagataliseer van sommigen hier die vinden dat dat geen vaart loopt, omdat in de projectjes die zij doen het nooit voorkomt.

Ook dat tabelnamen wel even hetzelfde zullen zijn is iets wat lekker weglult op een forum zoals dit maar in de praktijk kom je daar niet mee weg, wanneer de Oracle bak in de hoek jouw namen niet vreet omdat ze te lang zijn, of omdat de DB2 database is gebouwd met een versie die nog maar 8 characters toestond. Ga je dan roepen "dat is niet mijn probleem" ? Nee, je lost het op, en wel op de manier die het beste daartoe leent: in de mapping meta-data die TUSSEN class en table staat, niet IN de table en niet IN de class.

Wanneer je zelf je domain classes schrijft, is attribute based mapping de grootste miskleun die je kunt begaan, want vroeg of laat loop je tegen de nadelen aan van deze vorm van mappings.

Verwijderd schreef op donderdag 31 juli 2008 @ 09:55:
[...]
Nee simpelweg omdat het er zoals gewoonlijk niet om gaat wat je eigen ervaring is.

Nou, nu hebben wij te maken met duizenden klanten met veelal erg grote databases en ditto projecten. Nu stellen die klanten soms ons de vraag hoe multi-db op te lossen en al een aantal jaren geleden hebben we daar features voor toegevoegd zodat het makkelijk kan, zodat je .NET types die je wilt gebruiken via sqlserver ook op oracle bv kunt gebruiken zonder problemen. Het punt is een beetje dat wat jij beweert dat het nauwelijks voorkomt of niet echt nuttig is echt lulkoek is. Als je denkt dat je iets van deze materie afweet, denk dan even wat harder na voordat je wat roept in deze context. Bv, migratie van db A naar db B? Pakket wordt ontwikkelt voor Sqlserver, grote klant will licenses kopen maar heeft Oracle, kan dat ook? etc. Ga jij dan al de code door of pas je een mapping file aan?

Het gaat erom dat je meestal toch wel van te voren weet of je een domein model in verschillende datastores hebt. De uitzondering argumenten zijn dus niet ze gek veel waard. Zeker niet omdat je altijd nog je metadata met een tool uit je domein model kunt halen. Het is dus niet zo dat je je vast pint.

Je weet helemaal niet veelal van te voren of een applicatie alleen maar 1 db gaat gebruiken. En uitzonderingen zijn het al helemaal niet.

En welke tool gaat de attributes wijzigen dan voor je?

[...]
Wees dan veel duidelijker wat je punt is, want de enige die je maakt heb ik op gereageerd. Je punt is onderhoudbaarheid. Een van de facetten van onderhoudbare code is begrijpelijke code. Mapping bestandje hier, stukje code daar is voor nieuwe/andere mensen niet makkelijk om in te stappen. Vrij duidelijk als het bij de code staat.

blabla, wat je even vergeet is dat db specieke data ook in die mapping attributes staat, je kunt ze echt niet db generiek maken.

[ Voor 23% gewijzigd door EfBe op 31-07-2008 14:30 ]

[rrrandy]

EfBe schreef op donderdag 31 juli 2008 @ 14:05:

De meeste attribute based mappings hebben target DB specifieke informatie in zich, zoals field length, identity sequences, target types, etc. Dit is funest voor het hergebruiken van domain classes op andere databases. Men kan wel denken dat attribute based mappings alleen field names bevatten maar dat is onzin, daarmee kom je er niet. Je hebt hoe dan ook DB specifieke meta-data nodig en als je dat niet in mappings kwijt kunt, moet dat worden opgehaald at runtime.

En dan heb ik het nog niet eens over het gebrek aan type ABC op database X terwijl deze beschikbaar is op database Y (bit/bool bv). Je hebt dan conversie mappings nodig voor bv Oracle, maar niet voor SqlServer. Je domaincode blijft hetzelfde. DAT zijn problemen waar je tegenaanloopt bij multi-db, en ik erger me echt mateloos aan het gebagataliseer van sommigen hier die vinden dat dat geen vaart loopt, omdat in de projectjes die zij doen het nooit voorkomt.

Heb je een paar concrete voorbeelden? Ik heb NHibernate nooit gebruikt, maar ik kan me niet voorstellen dat het zoveel anders is dan Hibernate voor Java.

Een property declareer ik in mijn mapping bijvoorbeeld als String. Voor de ene DB genereert Hibernate een VARCHAR, voor de ander een VARCHAR2 etc.

Zo wordt een boolean in oracle een NUMBER(1,0) en in PostgreSQL een boolean.

Geef eens een paar voorbeelden van datatypen die je Hibernate vanuit je code niet direct naar een type kan mappen op de database en waarvoor je dat dus zelf moet specificeren?

EfBe schreef op donderdag 31 juli 2008 @ 14:05:
Ook dat tabelnamen wel even hetzelfde zullen zijn is iets wat lekker weglult op een forum zoals dit maar in de praktijk kom je daar niet mee weg, wanneer de Oracle bak in de hoek jouw namen niet vreet omdat ze te lang zijn, of omdat de DB2 database is gebouwd met een versie die nog maar 8 characters toestond. Ga je dan roepen "dat is niet mijn probleem" ? Nee, je lost het op, en wel op de manier die het beste daartoe leent: in de mapping meta-data die TUSSEN class en table staat, niet IN de table en niet IN de class.

Wat dit betreft heb je wel een punt. Omdat ik ook dingen bouw die met Oracle moeten kunnen samenwerken zorg ik dat alle indexes die ik definieer een unieke naam hebben en dat geen van de namen (tabellen, indexes, whatever) langer zijn dan 30 karakters. Met deze werkwijze heb ik nog nooit een applicatie gebouwd die niet zondermeer over te zetten was van Oracle naar PostgreSQL of voor mijn part MySQL. (SQLServer helaas (of gelukkig?) geen ervaring mee).

Waar ik zo de schurft aan heb met die mapping files is dat wanneer ik code toe wil voegen aan een class dat ik deze dan ook aan de mapping file moet toevoegen. Dat wil ik nog weleens vergeten. Ga je dan je code weer genereren, compileert de boel ineens niet meer...

[wasigh]

[quote]EfBe schreef op donderdag 31 juli 2008 @ 14:05:
[...]

[...]

De meeste attribute based mappings hebben target DB specifieke informatie in zich, zoals field length, identity sequences, target types, etc. Dit is funest voor het hergebruiken van domain classes op andere databases. Men kan wel denken dat attribute based mappings alleen field names bevatten maar dat is onzin, daarmee kom je er niet. Je hebt hoe dan ook DB specifieke meta-data nodig en als je dat niet in mappings kwijt kunt, moet dat worden opgehaald at runtime.

Maar is dan niet het probleem dat de mappings tegelijkertijd metadata over de class bevatten en configuratie gegevens? Je zou met een mappings tabel kunnen opgeven dat voor een oracle database integer(0,1) gebruikt moet worden voor een boolean en voor een SQL server een bool (of wat de exacte types dan ook mogen zijn, ik ben geen expert). Dat zou een configuratie bestand kunnen zijn die tijdens een project niet hoeft te veranderen.
Tuurlijk zul je wat trucjes uit moeten halen om de implementatie verschillen van databases goed af te handelen, maar waarom moet dat iedere keer in een mappingsfile. Waarom kan daar niet 1 keer een strategie voor gekozen en geimplementeerd worden?

Voor de goede orde: in mijn projectje ben ik bezig met een desktop applicatie die connect naar een meegeleverde SQLite database file. Ik maak de domein classes leidend en genereer daaruit het database schema. Ik snap dat dat niet vergelijkbaar is met heel veel andere projecten waar O/R mapping wordt toegepast

[Verwijderd]

EfBe schreef op donderdag 31 juli 2008 @ 14:05:
blabla, wat je even vergeet is dat db specieke data ook in die mapping attributes staat, je kunt ze echt niet db generiek maken.

En dat wil ik ook helemaal niet. Ik gebruik geen OR mapper omdat ik wil negeren dat ik een peperdure database server heb aangeschaft, ik gebruik een OR mapper ik me niet zo bezig wil houden met de vertaling van en naar, hence OR mapping...

Nu al rekening houden met het eventueel switchen van database server is zo'n onzinnige investering. Het kost simpelweg tijd om alles generiek te houden en mocht het er dan toch van komen dat je moet switchen dan is het verschil tussen generiek en specifiek eentje in de orde grote van een paar uutjes.

[EfBe]

rrrandy schreef op donderdag 31 juli 2008 @ 17:03:
[...]
Heb je een paar concrete voorbeelden? Ik heb NHibernate nooit gebruikt, maar ik kan me niet voorstellen dat het zoveel anders is dan Hibernate voor Java.

Een property declareer ik in mijn mapping bijvoorbeeld als String. Voor de ene DB genereert Hibernate een VARCHAR, voor de ander een VARCHAR2 etc.

Maar dit is veel te algemeen. Wat als ik een NVarchar wil, of een speciale collation? Wat als ik DB2 gebruik en sequences wil gebruiken voor identity values en niet 'identity' marked fields? etc. etc.

Zo wordt een boolean in oracle een NUMBER(1,0) en in PostgreSQL een boolean.

en een unique_identifier (sqlserver) in oracle? Of een Xml type uit oracle op mysql ? Alleen de plain types aangeven lukt niet.

wasigh schreef op donderdag 31 juli 2008 @ 21:38:
Maar is dan niet het probleem dat de mappings tegelijkertijd metadata over de class bevatten en configuratie gegevens? Je zou met een mappings tabel kunnen opgeven dat voor een oracle database integer(0,1) gebruikt moet worden voor een boolean en voor een SQL server een bool (of wat de exacte types dan ook mogen zijn, ik ben geen expert). Dat zou een configuratie bestand kunnen zijn die tijdens een project niet hoeft te veranderen.
Tuurlijk zul je wat trucjes uit moeten halen om de implementatie verschillen van databases goed af te handelen, maar waarom moet dat iedere keer in een mappingsfile. Waarom kan daar niet 1 keer een strategie voor gekozen en geimplementeerd worden?

Voor de goede orde: in mijn projectje ben ik bezig met een desktop applicatie die connect naar een meegeleverde SQLite database file. Ik maak de domein classes leidend en genereer daaruit het database schema. Ik snap dat dat niet vergelijkbaar is met heel veel andere projecten waar O/R mapping wordt toegepast

Je kunt een 'algemene' tabel maken van alle types in alle supported databases en dan voor alle databases waar die types niet bestaan ga je conversies definieren. Maar dit is maar de helft. 'string' als meta-type dat naar een DB type moet worden geconverteerd is te algemeen: welke collation, double byte of single byte? fixed length (char) of niet ? Bij numeric values heb je nog meer problemen. je komt een eind, maar het zit hem in de details: soms wil je specifieke mappinggegevens aangeven, domweg omdat je moet werken met een database die gemaakt is door een persoon die niet met (n)hibernate werkt (bv de DBA), en dit komt erg vaak voor.

[ Voor 50% gewijzigd door EfBe op 01-08-2008 09:39 ]