[J2EE|JBOSS] Unique index instellein in CMP met xDoclet

[PhoneTech]

Ik ben al een tijdje opzoek hoe je unique indexes kan aanmaken op CMP entity beans icm xDoclet.

momenteel heb ik een CMP user, met een userID als primary key (32 byte string GUID)
nu wil ik een unique index op de username hebben (wel zo handig)

Ik kan wel een ejbFinder maken (findByUsername) en vanuit daar bepalen of een username unique is of niet, maar ik wil eigenlijk gewoon een exception terug krijgen als ik een user aanmaak

Op http://xdoclet.sourceforg..._method-attributes__0__1_ kom ik ook niet echt verder.

primary key objecten is niet mogelijk. primary key moet een string blijven. Iemand een oplossing hier voor?

[Verwijderd]

lukt het niet om ipv

public Collection findByUserName(String userName)

dit:

public UserLocal findByUserName(String userName)

te nemen?

ik heb hier ergens een tabel met een primary key (fileId) en dan jaar en perId waar een unique constraint op rust. Die finder (ejbgen) wordt gewoon gedeclareerd met fileLocal getByPersonAndYear(Integer person, Integer year)...
(dit is natuurlijk weblogic maar lukt dat ook niet in jboss??)

[DaRKie]

waarom laat je de userid niet vallen. Als de username uniek moet zijn, dan is dit toch evengoed een pk. Waarom zou je aparte 2 pk fields gebruiken ?

[Verwijderd]

DaRKie schreef op dinsdag 08 maart 2005 @ 13:49:
waarom laat je de userid niet vallen. Als de username uniek moet zijn, dan is dit toch evengoed een pk. Waarom zou je aparte 2 pk fields gebruiken ?

omdat je dan in alle tabellen die gelinkt zijn met een user de username (varchar 16? meer?) als Foreign Key moet gebruiken terwijl een ID toch wel sneller zou zijn...

[PhoneTech]

Verwijderd schreef op dinsdag 08 maart 2005 @ 13:38:
lukt het niet om ipv

public Collection findByUserName(String userName)

dit:

public UserLocal findByUserName(String userName)

te nemen?

ik heb hier ergens een tabel met een primary key (fileId) en dan jaar en perId waar een unique constraint op rust. Die finder (ejbgen) wordt gewoon gedeclareerd met fileLocal getByPersonAndYear(Integer person, Integer year)...
(dit is natuurlijk weblogic maar lukt dat ook niet in jboss??)

Ik heb de methode UserLocal findByUserName al geimplementeerd, maar hoopte eigenlijk dat ik het aan de DB over kon laten...

Ik denk dat ik me er bij moet neerleggen dat ik voor een CRUD kijk of hij unique is.

[PhoneTech]

Verwijderd schreef op dinsdag 08 maart 2005 @ 14:07:
[...]


omdat je dan in alle tabellen die gelinkt zijn met een user de username (varchar 16? meer?) als Foreign Key moet gebruiken terwijl een ID toch wel sneller zou zijn...

Heb je gedeeltelijk gelijk in. Zoiezo is het IMHO not done om een user value als PK te gebruiken.

Ik gebruik een 32bits string als primary key. we gebruiken oracle 10g als DB, en die heeft er absoluut geen performance problemen mee als je een string als key gebruikt ipv een int.
dit is een Globally Unique ID die er ongeveer zo uitziet: 816627700a00004c01f87254ae3e5090

[Verwijderd]

inderdaad, primary keys worden geacht geen echte (business logic) betekenis te hebben...

ow, ik herlees net je eigenlijke probleem. Waarom maak je gene unique constrait in je database? JBoss zal dan wel een EJBException gooien als die constraint overtreden wordt (iemand met een identieke naam wordt toegevoegd). Zo gebeurt het hier...je moet zo'n dingen op een zo laag mogelijk niveau definieren. Het is de database die zulke dingen moet afdwingen, het echt niet mogelijk maken om unique constraints met de voeten te treden. JBoss krijgt een SQLException en gooit die door als EJBException, probleem opgelost. (enkel de EJBException afvangen en een mooier foutboodschapje geven )

oracle:


CREATE UNIQUE INDEX USER_UK ON APP_USERS
(USR_FIRST_NAME, USR_LAST_NAME)


ik zie echt niet wat XDoclet hier komt doen.
(je genereert je databaseschema toch niet vanuit je CMP definities? Dat is als je DB schema vanuit je Hibernate mapping files creëren, ben ik absoluut geen voorstander van.... maar ik lijk de enige te zijn)

[ Voor 85% gewijzigd door Verwijderd op 08-03-2005 14:55 ]

[PhoneTech]

Verwijderd schreef op dinsdag 08 maart 2005 @ 14:48:
inderdaad, primary keys worden geacht geen echte (business logic) betekenis te hebben...

ow, ik herlees net je eigenlijke probleem. Waarom maak je gene unique constrait in je database? JBoss zal dan wel een EJBException gooien als die constraint overtreden wordt (iemand met een identieke naam wordt toegevoegd). Zo gebeurt het hier...je moet zo'n dingen op een zo laag mogelijk niveau definieren. Het is de database die zulke dingen moet afdwingen, het echt niet mogelijk maken om unique constraints met de voeten te treden. JBoss krijgt een SQLException en gooit die door als EJBException, probleem opgelost. (enkel de EJBException afvangen en een mooier foutboodschapje geven )

oracle:


CREATE UNIQUE INDEX USER_UK ON APP_USERS
(USR_FIRST_NAME, USR_LAST_NAME)


ik zie echt niet wat XDoclet hier komt doen.
(je genereert je databaseschema toch niet vanuit je CMP definities? Dat is als je DB schema vanuit je Hibernate mapping files creëren, ben ik absoluut geen voorstander van.... maar ik lijk de enige te zijn)

Waarschijnlijk zal er wel een SQL script komen die na de deployment gedraait wordt ja
xDoclet gebruiken we hier om de deployment descriptors, localhome, home en remote interfaces te laten genereren.

Het database schema wordt tijdens development gewoon door de applicatie server gegenereerd. is wel zo makkelijk met de vele wijzigingen.

Als het schema eenmaal vast ligt, dan wordt dat uitgezet, en kan aan de datamigratie begonnen worden.

[Verwijderd]

PhoneTech schreef op dinsdag 08 maart 2005 @ 15:51:
[...]


Waarschijnlijk zal er wel een SQL script komen die na de deployment gedraait wordt ja
xDoclet gebruiken we hier om de deployment descriptors, localhome, home en remote interfaces te laten genereren.

Het database schema wordt tijdens development gewoon door de applicatie server gegenereerd. is wel zo makkelijk met de vele wijzigingen.

Als het schema eenmaal vast ligt, dan wordt dat uitgezet, en kan aan de datamigratie begonnen worden.

dat komt omdat JBoss zijn CMP engine op Hibernate gebaseerd heeft, en hibernate heeft een tool om van je hibernate mappings (of CMP mappings in dit geval) DDL te genereren. Ik ben er absoluut niet voor (tijdens de development fase kan ik het nog begrijpen, maar voor productieomgevingen??)
Ga je echt de optimalisatie van een productie omgeving laten afhangen van de grillen van de automatische creatie van je DB schema???

Volgens mij heeft dit dus ook niets met JBoss te maken
Wat ik beter vind is omgekeerd werken, je DB schema maken (handmatig) en daaruit je Objecten+Mappings genereren, kan dat?

[PhoneTech]

We hebben ons systeem uit het domain model ontworpen. Dan kan je niet meteen met een DB model beginnen. De keuze voor CMP als persistance technology heb ik niet in de hand.

Over het DB schema? Daar ben ik redelijk tevreden over. Met de goede tags kan xdoclet & jboss een aardige DDL genereren MET referentiele integriteit.
Performance tunen kan altijd nog. Daar maak ik me nu niet zo een zorgen om..