Daniel John Debrunner wrote:
> I'm looking at how James uses Derby
Your observations aside, JAMES can be far more efficient in its management
of data than it is at present. Too much copying. dbfile is more efficient,
and I'd like to see us separate mail (associates state, attributes and
recipients with a message) from message, so that we have fewer copies and
don't need to move the message when mail switches between processors.
Back to your comments ...
> I'm curious about the recipients and {message_body, message_attributes}
> fields.
> recipients long varchar - In Derby LONG VARCHAR has a limit of 32,700
> characters. Does this limit James in any way?
As per RFC 2821, an e-mail address is limited to 320 characters, so we'd be
good for 100 addresses, which is the minimum permitted by the RFC.
Practically, we would be good for far more than the minimum.
> A better datatype would be CLOB, then you could have up to 2Gb character
limit.
> I don't believe this would require any application changes (moving to a
CLOB).
We've seen some odd behavior dealing with CLOBs with some drivers, hence the
useBlob vs useBytes attibute in sqlResources. Would that apply here?
> message_body, message_attributes are defined as BLOB, this means
> BLOB(1M), a one megabyte blob. Is this a concern for James?
> (http://db.apache.org/derby/docs/10.1/ref/rrefblob.html)
Possibly, yes, thanks. Other databases have similar limits. Personally,
I'd suggest that until the aforementioned changes are made, anyone accepting
large e-mail (a maximum message size can be configured in the SMTP handler)
be using dbfile, rather than db.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
