I use key fields of 16 bytes a piece (GUID). I keep them in String's for
compatibility and portability (not every server supports db schemas the way
orion does). I find imperative that these Strings can be identified with any
non-java db tool (as opposed to a serialized instance).
some entities model a composite key, with perhaps 8 different fields,
depending on the mapping, it adds up to 256 or 2048 bytes...
-----Original Message-----
From: Stan Ng [mailto:[EMAIL PROTECTED]]
Sent: Viernes, 12 de Enero de 2001 22:04
To: Orion-Interest
Subject: Re: Re[2]: large field bug ??
just out of curiousity, why would you want to use a really long string as a
primary key? from a db perspective, the performance would be seriously
compromised.
----- Original Message -----
From: "Juan Lorandi (Chile)" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Friday, January 12, 2001 1:26 PM
Subject: RE: Re[2]: large field bug ??
I use String for primary/composite key fields... there are size constraints
in many DB's about the total length of a PK
so i still need String mapped to varchars, plus it will be DB accepted to
use it as PrimKey (opposed to BLOBs)
The mix approach doesn't sound nice, but it works and is flexible enough to
handle most odd situations
My 2c,
JP
-----Original Message-----
From: Rafael Alvarez [mailto:[EMAIL PROTECTED]]
Sent: Sábado, 09 de Diciembre de 2000 10:11
To: Orion-Interest
Subject: Re[2]: large field bug ??
Hello Juan,
Thursday, January 11, 2001, 3:53:41 AM, you wrote:
JLC> had that problem....
JLC> it's a mapping problem... (oracle-schema)
JLC> Strings get Mapped to varchars(size)...
JLC> They get chopped at size chars...
JLC> the only solution is to declare the field as java.lang.Object
JLC> then use it as string
Or you can edit orion-ejb-jar.xml and change the type of the field in
the DB. The schema set it to varchar(255), but you can change it to
any oracle type you want. look for a line like
<cmp-field-mapping ..... persistence-type="varchar2(255)" ..>
change that and voila!
--
Best regards,
Rafael mailto:[EMAIL PROTECTED]
