Hibernate - Primary Key ändern

[freez]

Hallo,

ich habe 2 Tabellen in MySQL zu authetifizierung über einen JDBC Realm nach dem Schema:

create table member (
  email                varchar(15) not null primary key,
  user_pass         varchar(15) not null
);

create table roles (
  email       varchar(15) not null,
  role         varchar(15) not null,
  primary key (user_name, role_name)
);

Zusätzlich habe ich noch eine Fremdschlüsselbeziehung zwischen "email".

Nun habe ich mit MyEclipse die Tabellen per Reverse Engineering ins Projekt geholt und habe nun 5 Klassen (Member, MemberDAO, Roles, RolesDAO und RolesId).

Ich habe mir nun alle Rollen über den Member geholt (Member.getRoles()) und wollte eine Rolle mit folgenden Code verändern:

                MemberDAO dao = new MemberDAO();
		RolesDAO rdao = new RolesDAO();
                //Weiterer Code um die Daten zu holen

                Set roles1 = member.getRoleses();
		
		Iterator it = roles1.iterator();
		if(it.hasNext()){
			Roles role = (Roles) it.next();			
			System.out.println(role.getId().getRole());
			RolesId id = role.getId();
			id.setRole("customer");
			rdao.save(role);
		}
		

		rdao.getSession().flush();
		

		rdao.getSession().close();
		dao.getSession().close();

Allerdings ändert sich nichts in der Datenbank. Was mache ich verkehrt?

 

[freez]

Problem gelöst. Ein AutoCommit= TRUE, bzw. das Save in einer Transaction war die Lösung.

 

[tfa]

Warum benutzt du solche Sachen wie Email-Adresse und Username als Primärschlüssel? Das wird spätestens dann problematisch wenn sich diese Daten ändern.

 

[freez]

Naja, ganz einfach: die email Adresse muss eindeutig sein, und bevor ich in meiner Anwendung prüfe, ob eine Adresse schon existiert, lasse ich es die Datenbank übernehmen.

Oder hole ich mir mit dieser vorgehensweise andere Probleme ins Haus?

 

[GilbertGrape]

Wenn du die Spalte für die Emailadresse Unique machst, dann ist die auch eindeutig.

 

[tfa]

Oder hole ich mir mit dieser vorgehensweise andere Probleme ins Haus?

Tust du. Wenn ein Anwender z.B. seine Emailadresse ändern will, musst du unter Umständen dutzende Datensätze anfassen -- falls das überhaupt funktioniert.
Daten, die irgendwie eingegeben oder angezeigt werden, haben in Primärschlüsseln nichts zu suchen.

 

[freez]

@GilbertGrape: danke für den Tipp

@tfa: hm, ok ... aber für den JDBCRealm von Tomcat wird es unter tomcat.apache.org/tomcat-6.0-doc/realm-howto.html so vorgeschlagen. Sollte ich es anders machen? Wenn ja, wie?

 

[maki]

hm, ok ... aber für den JDBCRealm von Tomcat wird es unter tomcat.apache.org/tomcat-6.0-doc/realm-howto.html so vorgeschlagen.

Da wird nirgends die email zum PK erhoben.. abgesehen davon zeigt die TC Doku wie man einen JDBCRealm einrichtet, nicht man man Relationale Schema anlegen sollte

Keine fachlichen Schlüssel zum PK zu machen ist eigentlich Standard

 

[tfa]

Wenn das diese Software so vorschlägt, kannst du das natürlich machen (es sind ja nur Beispiele). Es ist halt eine Vereinfachung, da man sich nicht um die Kunstschlüsselgenerierung kümmern muss. Dann musst du dich allerdings damit abfinden, dass sich die Email-Adresse oder der Name eines Benutzers nicht nachträglich ändern lassen (oder nur mit großem Aufwand).

Alternativ musst du halt jeder Tabelle einen "Surrogate Key" als Primärschlüssel geben, z.B. einen Integer. Viele Datenbanken können diese Kunstschlüssel autoamtisch erzeugen (Sequenzen, "auto_increment").
Mehr zu dem Thema:
http://www.agiledata.org/essays/keys.html

 

[freez]

@maki: in dem Realm HowTo steht dort "user_name" ... ich habe es nur umbenannt zu email, da bei mir der Username die email adresse ist. und da ist der user_name schon ein PK.

Das der user_name nicht als FK benutzt wird ist richtig ... aber ich wollte in Hibernate von der Member Class auf die Rollen zugreifen, was mir bei einer Fremdschlüsselbeziehung ja richtig gut gelingt. Ausserdem sollte doch mit der CASCADE Option die Änderung der email direkt auf die Role Table übergreifen ... und sollte es ein Problem dabei geben, darf diese Änderung nicht übernommen werden (stelle ich mir in der Theorie so vor ... habe ich noch nicht praktisch getestet)

@tfa:

Dann musst du dich allerdings damit abfinden, dass sich die Email-Adresse oder der Name eines Benutzers nicht nachträglich ändern lassen (oder nur mit großem Aufwand).

da die spalte email der username ist, ist das Ändern dieser doch auch nicht größer, wie beim Anlegen.

... aber im Endeffekt arbeite ich auch lieber mit Integer bei PK's ... Nur in dem Realm wusste ich nicht, ob das funktioniert und habe das Beispiel einfach so übernommen und noch ne Fremdschlüsselbeziehung eingerichtet um Inkosistenzen zu vermeiden.

 

[Guest]

@maki: in dem Realm HowTo steht dort "user_name" ... ich habe es nur umbenannt zu email, da bei mir der Username die email adresse ist. und da ist der user_name schon ein PK.

Das der user_name nicht als FK benutzt wird ist richtig ... aber ich wollte in Hibernate von der Member Class auf die Rollen zugreifen, was mir bei einer Fremdschlüsselbeziehung ja richtig gut gelingt. Ausserdem sollte doch mit der CASCADE Option die Änderung der email direkt auf die Role Table übergreifen ... und sollte es ein Problem dabei geben, darf diese Änderung nicht übernommen werden (stelle ich mir in der Theorie so vor ... habe ich noch nicht praktisch getestet)

@tfa:

Dann musst du dich allerdings damit abfinden, dass sich die Email-Adresse oder der Name eines Benutzers nicht nachträglich ändern lassen (oder nur mit großem Aufwand).

da die spalte email der username ist, ist das Ändern dieser doch auch nicht größer, wie beim Anlegen.

... aber im Endeffekt arbeite ich auch lieber mit Integer bei PK's ... Nur in dem Realm wusste ich nicht, ob das funktioniert und habe das Beispiel einfach so übernommen und noch ne Fremdschlüsselbeziehung eingerichtet um Inkosistenzen zu vermeiden.

Ein Update auf einen Primärschlüssel funktioniert in Hibernate nur über einen Query.

Sowas wie

String key = "a@b.de";

MyObject o = session.get(MyObject.class, key);
// nun die Mail ändern
o.setKey("c@d.de");

session.merge(o);

geht nicht, da Hibernate das Objekt nicht findet um einen Update zu machen.

Der Update den Hibernate produzieren würde wäre

UPDATE MyObject o set o.email = 'c@d.de' WHERE o.email = 'c@d.de';

da Hibernate um das Objekt zu identifizieren immer den Primärschlüssel nimme. Und genau diesen Primärschlüssel hast du davor manuell geändert.

Ich arbeite schon lange mit Hibernate und habe auch das Problem das ich Primärschlüssel aktualisieren muss (und ich habe keine Alternative das anders zu lösen) und ich kann dir nur raten: Finger weg.

Ein paar Gründe warum ich absolut gegen fachliche Felder im PK bin:
- Felder können sich häufig ändern -> diese Änderung zieht sich durch alle referenzierten Objekte
- Felder können wegfallen
- Felder können aus fachlicher Sicht gleiche Einträge enthalten
- Felder sind irgendwann nichtmehr eindeutig
u.s.w.