[Nhibernate] Any-Mapping

[418O2]

Ik zit met het volgende:

Ik heb een applicatie (gemaakt met WCSF, C#.net, Asp.net en NHibernate). Maar nu heb ik verschillende attachments.

Nu is de <any> mapping mij bekend, maar alleen one-way. Ik gebruik het nu om de relatie tussen een account en een persoonsobject aan te geven, maar dat is maar 1 kant op. De andere kant op is het in principe een many-to-one, maar ik krijg dat niet goed voorelkaar.

Hij kijkt namelijk alleen naar de foreign-key, niet naar het type, dat ook in de child wordt aangegeven... Dus een discriminator aangeven wil niet. Een any-to-one of one-to-any kan ik niet vinden.

wie kan mij verder helpen ?

[BalusC]

NHibernate Reference Documentation

Kun je hier niks mee? Ik heb het niet doorgebladerd, maar de Java versie bevat uitmuntende voorbeelden

[418O2]

al 100x ongeveer, superhandig document wel, maar de oplossing van mijn probleem kom ik er niet in tegen.

[whoami]

Kan je eens kort tonen hoe je DB model er uit ziet, hoe je classes er uit zien (diagrammetje), en hoe je mapping er uit ziet ?

[418O2]

Het zijn allemaal vrij standaard classes. Wat we nu hebben is een attachment_object_class (de class van de parent) en attachment_object_id (het id van de parent). Het attachment heeft dus de classname + id van de parent in zich...

[418O2]

Dat is het ongeveer. Een note kan 1 attachment hebben. Maar de note moet bij verschillende objecten kunnen horen. De note moet dan opslaan bij welke hij hoort. Ik heb dit wel eens geprobeerd en het werkt wel van de note naar de parent, maar anders om wil het niet. Je kan wel een many-to-one maken, maar ik weet niet hoe je dan aangeeft dat hij kijkt naar de parent_object_class.

Het wil uiteraard wel met koppeltabellen, maar als dit goed werkt is het makkelijker natuurlijk, te meer je dan netjes van de child naar de parent kan, met koppeltabellen werkt dat ook weer niet zo lekker, omdat de child dan alle koppeltabellen langs moet.

_{Het is een amateur 1.0 plaatje, maar het maakt het wel wat duidelijker.}

[EfBe]

Heb je 2 parents voor Note? Of meerdere FK's naar meerdere parents? In beide gevallen is het vragen om moeilijkheden. een M:N relatie is nu eenmaal niet te maken zonder een intermediate entity.

[418O2]

de parents hebben sets van notes. Een note hoort altijd bij 1 parent, nooit bij 0, nooit bij > 1.

Bij NHibernate heb je de anymapping waarbij je dat kan aangeven, dan zou ik van een note naar een parent kunnen, maar andersom is toch echt noodzakelijk in dit geval.

[ Voor 46% gewijzigd door 418O2 op 12-11-2008 14:26 ]

[EfBe]

418O2 schreef op woensdag 12 november 2008 @ 14:26:
de parents hebben sets van notes. Een note hoort altijd bij 1 parent, nooit bij 0, nooit bij > 1.

Bij NHibernate heb je de anymapping waarbij je dat kan aangeven, dan zou ik van een note naar een parent kunnen, maar andersom is toch echt noodzakelijk in dit geval.

Dat is toch gewoon een 1:n relatie? (Parent 1:n note) ? Dit kan alleen wanneer note een FK heeft naar parent. Daarom vroeg ik: heeft note meerdere parents, en dus meerdere FK's. Indien ja, dan moet je in note meerdere FK fields aanmaken OF een koppeltabel.

[418O2]

Het is dus mogelijk om dit door NHibernate af te laten vangen. Dat is onderhoudstechnisch beter en beter uitbreidbaar.

[EfBe]

418O2 schreef op donderdag 13 november 2008 @ 10:15:
Het is dus mogelijk om dit door NHibernate af te laten vangen. Dat is onderhoudstechnisch beter en beter uitbreidbaar.

Lijkt me wat overtrokken:

It is impossible to specify a foreign key constraint for this kind of association, so this is most certainly not meant as the usual way of mapping (polymorphic) associations. You should use this only in very special cases (eg. audit logs, user session data, etc).

ref:
http://www.hibernate.org/...#mapping-types-anymapping
Die laatste opmerking slaat op een 1-way relationship die je hierdoor krijgt. Dus wat jij wilt kan niet, tenzij je het een volwaardige relationship maakt, wat niet meer dan logisch is, lijkt me. En sorry, maar 'any' mappings zijn niet beter te onderhouden, in tegendeel.

[whoami]

Als het een 1-to-1 mapping is, kan je dan niet beter een component (mapping) gebruiken ?
Het lijkt me dat een attachment geen entiteit is , maar een value-object ?

[418O2]

Het attachment is enkel een bestand, evt meerdere per note.

Mijn idee is dat ik dan met 1 entiteit (de note) toe kan, om notities bij heel veel andere entiteiten bij te kunnen houden op een manier waar op je ook nog weer van die note naar de parent kan, zonder eerst alle properties te checken of ze leeg zijn of niet.

[whoami]

418O2 schreef op donderdag 13 november 2008 @ 14:04:
Het attachment is enkel een bestand, evt meerdere per note.

Nu begin je wel je requirements te veranderen hé:

418O2 schreef op woensdag 12 november 2008 @ 11:37:

Dat is het ongeveer. Een note kan 1 attachment hebben. Maar de note moet bij verschillende objecten kunnen horen.

Waarom neem je in je note tabel gewoon niet een veld 'ticketid' & 'projectid' op, waarbij je er voor zorgt dat juist één van die velden ingevuld is ?
Je hebt dan in je domain model een class Ticket die een collectie van Notes heeft, en een class Project die een collectie van Notes heeft.

[ Voor 58% gewijzigd door whoami op 13-11-2008 14:54 ]

[418O2]

Ja dat snap ik, maar in sommige systemen moet ik bij meer dan 2 (zeg 5) entiteiten, die sets aanmaken, dan krijg je dus 5 velden waarvan 1 is ingevuld. Is dat normalisatietechnisch gezien wel oke dan ?

1 attachment kan ook wel. Die heb ik los getrokken omdat het 1 of 0 is.

[Mental]

Als je nou gewoon als FK in attachment de ID van Note gaat gebruiken, kan je zoveel attachements per note aanmaken als je wilt zonder de note meerdere keren aan te moeten maken.

Maar dat is hiervoor ook al een paar keer geroepen, 1:n relatie ring a bell?
Misschien is het praktisch om niet met allerlei termen te gaan gooien terwijl je de taal niet goed beheerst


offtopic: dit stinkt naar huiswerk.

[ Voor 5% gewijzigd door Mental op 13-11-2008 15:07 ]

[418O2]

Ja dat snap ik wel. Alleen vroeg ik mij dus af of je op enige wijze kan bewerkstelligen dat je zonder per entiteit een veld te maken die relatie kan aangeven. Normaal gesproken heeft entiteit 1 een relatie met entiteit 2. maar nu heeft ent. 1 een relatie met ent 2 of ent3 of ent4 etc.

Maar ik denk dat het er op neer komt dat ik gewoon een veld per parent moet maken.

edit: zeker geen huiswerk hoor.

[ Voor 4% gewijzigd door 418O2 op 13-11-2008 15:08 ]

[Mental]

418O2 schreef op donderdag 13 november 2008 @ 15:08:
Ja dat snap ik wel. Alleen vroeg ik mij dus af of je op enige wijze kan bewerkstelligen dat je zonder per entiteit een veld te maken die relatie kan aangeven. Normaal gesproken heeft entiteit 1 een relatie met entiteit 2. maar nu heeft ent. 1 een relatie met ent 2 of ent3 of ent4 etc.

Maar ik denk dat het er op neer komt dat ik gewoon een veld per parent moet maken.

edit: zeker geen huiswerk hoor.

Nouja, opzich gewoon een kwestie van logisch nadenken he.

Neem een bak met rode papiertjes en een bak met witte papiertjes.
Als elk rode papiertje bij 1 wit papiertje hoort kun je op allebei de papiertjes hetzelfde nummer zetten.

Als bij elk rood papiertje meerdere witte papiertjes horen zul je op alle papiertjes hetzelfde nummer moeten zetten.
Maarrrr, aangezien je dan geen onderscheid meer kunt maken tussen de verschillende witte papiertje zal je daar ook een apart nummer op moeten zetten.

Maw: extra key (parentid bijv.) in attachment die refereert naar Id in note.

[ Voor 0% gewijzigd door Mental op 13-11-2008 15:15 . Reden: typo ]

[418O2]

Alleen heb je met stapels papieren geen laag ertussen die eea aanelkaar kan linken

Maar het is duidelijk. Jammer maar helaas, had gehoopt dat het zo had gewerkt

[whoami]

Misschien heb je hier nog iets aan:
klik

[418O2]

het is inmiddels opgelost

C#:

<set name="x" cascade="all" inverse="true" where="booking_object_class='THISCLASSNAME'">
        <key column="THISCLASSNAME_object_id" />
        <one-to-many class="x.X.x" />
      </set>

[ Voor 10% gewijzigd door 418O2 op 20-11-2008 10:23 ]