Same here, but it's sometimes handy to overwrite annotations.

I just committed http://svn.apache.org/viewvc?rev=1058984&view=rev : you can use the jpa-mappings.xml to redefine the HEADER_VALUE column from 4000 (defined by annotation) to 8000.

I think we meet the database vendors requirements, having a base working for all, being updated if needed by James Administrator.

Tks,

Eric


On 11/01/2011 19:40, Norman Maurer wrote:
I'm still no fan of xml files for JPA.. but maybe thats just me

Bye,
Norman

2011/1/11 Eric Charles<[email protected]>:
Yes, we can do that, with default being "do not trim".
We can also add some xml mapping files with overrides that column with
default value 4000, so administrator can change easily change it for
database which support it (see also
https://issues.apache.org/jira/browse/IMAP-233).

Tks,

Eric

On 11/01/2011 18:56, Norman Maurer wrote:
what about making it configurable ?

Bye,
Norman

2011/1/11 Eric Charles<[email protected]>:
VARCHAR for searches must remain.
But persist trimed values sounds strange to me: it's like having untrue
information...
It may be better than failing to persist in database, I don't know.

Tks,
Eric


On 11/01/2011 18:24, Norman Maurer wrote:
We need to use VARCHAR if we want to optimize search queries later and
filter on header names / values..

Maybe using 4000 would be the best and just "trim" down the header
value if we need to..

wdyt ?

Norman

2011/1/11 Eric Charles<[email protected]>:
Hi,

We are working right-now to fix the DB column names (see
https://issues.apache.org/jira/browse/MAILBOX-14).

1. Column of type VARCHAR was OK on MySQL and Derby for length 10240.
Could
you advice us another type, so we could fix it via JPA annotations.
From
the
message, it seems we should go to BLOB/CLOB. Another option would be to
lower 10240 to 4000: I remember we took a security margin for very
large
headers but 4000 could fit that margin...

2. It should be soon resolved cause with the proposed patch (not-yet in
trunk), we prefix tables and columns with context. For example uid
column
will be MAIL_UID.

Running James with Oracle DB is of course a top priority, so your
feedbacks
will be very helpful.

Tks,

Eric


On 11/01/2011 15:53, Marcin Kieć wrote:
After setting db properties to oracle I get ORA-exception:

1. ORA-00910: specified length too long for its datatype
while executing statement: CREATE TABLE Header (id NUMBER NOT NULL,
field
VARCHAR2(1024), lineNumber NUMBER, value VARCHAR2(10240), MESSAGE_ID
NUMBER,
PRIMARY KEY (id))

Reason: max length of VARCHAR2 in Oracle is 4000 (length in definition
of
column value is set to 10240). Only BLOB/CLOB can hold data that
exceeds
4000B size.

2. After createing table Header by my self in database I get another
error
while starting James server:
ORA-00904: invalid identifier
while executing statement: CREATE TABLE Membership (mailboxId NUMBER
NOT
NULL, uid NUMBER NOT NULL, answered NUMBER, deleted NUMBER, draft
NUMBER,
flagged NUMBER, internalDate TIMESTAMP, recent NUMBER, seen NUMBER,
MESSAGE_ID NUMBER, PRIMARY KEY (mailboxId, uid))

Reason: uid is reserved identifier in oracle and cannot be used as a
column name.

Is there any way to run James with persistance in Oracle DB?

Best regards
Marcin

----------------------------------------------------------------
Auta nowe i używane, duże i małe - największa baza!
Sprawdź>>        http://linkint.pl/f28df


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to