NHibernate eins-zu-eins-Zuordnung, wo die zweite Tabelle die Daten können null sein
Ich habe eine bestehende Datenbank mit der Tabelle der Transaktionen. Ich habe eine neue Tabelle namens TransactionSequence, wo jede Transaktion, die letztendlich nur einen Datensatz. Wir sind mit der Sequenz-Tabelle zu zählen, die Transaktionen für ein bestimmtes Konto. Ich habe zugeordnet, dies als eine eins-zu-eins-Zuordnung, wo TransactionSequence hat einen primären Schlüssel, der Transaktions-id.
Die Einschränkung ist, dass es ein instead of-trigger für die Transaktion Tabelle nicht Aktualisierungen von storniert oder gebucht Transaktionen.
So, wenn die Sequenz wird berechnet und der Transaktion gespeichert, NHibernate zu senden versucht ein update auf die Transaktion wie 'UPDATE-Transaktion Transaktions-id = ? WO Transaktions-id = ?'. Aber dies schlägt fehl, da der trigger. Wie kann ich konfigurieren mein mapping so, dass NHibernate wird nicht versuchen, ein update der transaktionstabelle, wenn eine neue TransactionSequence Tabelle eingefügt wird?
Transaktion Abbildung:
<class name="Transaction" table="Transaction" dynamic-update="true" select-before-update="true">
<id name="Id" column="ID">
<generator class="native" />
</id>
<property name="TransactionTypeId" access="field.camelcase-underscore" />
<property name="TransactionStatusId" column="DebitDebitStatus" access="field.camelcase-underscore" />
<one-to-one name="Sequence" class="TransactionSequence" fetch="join"
lazy="false" constrained="false">
</one-to-one>
</class>
Und die Reihenfolge, Zuordnung:
<class name="TransactionSequence" table="TransactionSequence" dynamic-update="true">
<id name="TransactionId" column="TransactionID" type="Int32">
<generator class="foreign">
<param name="property">Transaction</param>
</generator>
</id>
<version name="Version" column="Version" unsaved-value="-1" access="field.camelcase-underscore" />
<property name="SequenceNumber" not-null="true" />
<one-to-one name="Transaction"
class="Transaction"
constrained="true"
foreign-key="fk_Transaction_Sequence" />
</class>
Jegliche Hilfe würde sehr geschätzt werden...
InformationsquelleAutor SteveBering | 2008-10-28
Du musst angemeldet sein, um einen Kommentar abzugeben.
Eins-zu-eins-mapping, nhibernate nicht so, wie Sie denken, es tut. Es ist so konzipiert, dass Sie haben zwei Klassen, die, wenn Sie persistiert, um Ihre entsprechenden Tabellen haben den gleichen Primärschlüssel.
Aber Sie können es schaffen, aber es ist nicht schön. Ich werde Ihnen zeigen, wie dann bieten sich einige alternativen:
In der Transaktion hbml:
In Ihrer Sequenz html:
Diese sollte tun, was Sie wollen, es zu tun. Hinweis: die Eigenschaft-ref.
Die nächste Frage, die Sie gehen, um auf Fragen, wie Sie bekommen, lazy loading auf eins-zu-eins-Assoziationen. Die Antwort ist, können Sie nicht... gut Sie können, aber es wird wahrscheinlich nicht funktionieren. Das problem ist, dass Sie Ihre foreign key auf die sequence-Tabelle, was bedeutet, dass nhibernate hat für die hit-Datenbank um zu sehen, ob das Ziel existiert. Dann können Sie versuchen, das Spiel mit eingeschränkten="true/false", um zu sehen, wenn Sie davon überzeugen können, es zu träge Last des one-to-one-Assoziation.
Alles in allem, es wird Ergebnis in eine totale Verschwendung von Ihrer Zeit.
Schlage ich vor, entweder:
Dadurch sparen Sie eine Menge Kopfschmerzen auf lange Sicht.
many-to-one
Verbände? Ursache einer von Ihnen muss der Fremdschlüssel der anderen Tabelle.InformationsquelleAutor jonnii
Stellt sich heraus, dass für meine situation eine
<join table>
mapping besten funktioniert. Ich musste nur sicherstellen, dass ich die Eigenschaften, die kam aus der zweiten Tabelle wurden nullable-Typen, - oder es tun würde, ein einfügen auf speichern, auch wenn sich nichts geändert hätte. Da brauchte ich nicht lazy loading für die zweite Tabelle, das funktioniert Super. Ich bin sicher, ich hätte gepaart, viele-zu-eins-Zuordnungen arbeiten, aber es war nicht intuitiv und scheint komplizierter als die join-Tabelle option, jedoch<join table>
ist nur in NHibernate 2.0.InformationsquelleAutor SteveBering