The following issue has been RESOLVED. ====================================================================== http://www.dbmail.org/mantis/view.php?id=280 ====================================================================== Reported By: kc Assigned To: paul ====================================================================== Project: DBMail Issue ID: 280 Category: Database layer Reproducibility: always Severity: minor Priority: normal Status: resolved Resolution: fixed Fixed in Version: SVN Trunk ====================================================================== Date Submitted: 06-Nov-05 07:55 CET Last Modified: 14-Feb-06 16:56 CET ====================================================================== Summary: Encoded subject causes db error when save data to dbmail_subjectfield as length exceeds 100 Description: table dbmail_subjectfield has only 100 char for subjectfield. In the case the subject is in utf-8, it need to be encoded which makes it larger than expected.
Suggest to use "text" instead of varchar(100). I don't know if there is any RFC limits subject length line though. And, shouldn't the subject line be decoded when save it to dbmail_subjectfield? ====================================================================== ---------------------------------------------------------------------- paul - 06-Nov-05 14:19 ---------------------------------------------------------------------- The code truncates basesubject values to a strlen of 255. The add_header_tables.pgsql did not reflect the change in the code. Why do you think the basesubject should be decoded? Please understand the subjectfield table is used only for THREAD=orderedsubject and for SEARCH HEADER SUBJECT "somevalue". So we need to be able to do LIKE and ORDER BY queries efficiently on this field. Also, I want to keep dbmail as charset/encoding agnostic as possible. ---------------------------------------------------------------------- kc - 06-Nov-05 23:01 ---------------------------------------------------------------------- Indeed, the sql for pgsql is different from mysql, including datefield in pgsql as varchar(100) instead of timestamp. I'll make changes according to mysql file then. btw, found a lot of unique index based on (physmessage_id, id). Since id is primary, it already ensured uniqueness. Issue History Date Modified Username Field Change ====================================================================== 06-Nov-05 07:55 kc New Issue 06-Nov-05 14:19 paul Note Added: 0000951 06-Nov-05 23:01 kc Note Added: 0000952 14-Feb-06 16:56 paul Status new => resolved 14-Feb-06 16:56 paul Fixed in Version => SVN Trunk 14-Feb-06 16:56 paul Resolution open => fixed 14-Feb-06 16:56 paul Assigned To => paul ======================================================================
