AW: (patch) Another case of duplicate keys (via dbmail-smtp)

What me (duplicate key issue) wonders even more: why using
db-keys without an autoincrement field? This may is some
kind of code-issue but it is definetly also a db-model
issue. What reason the key has no autoincrement field?
current: UNIQUE KEY `physmessage_id_2`
(`physmessage_id`,`headername_id`,`headervalue`(255))
well, this cries for a duplicate key error, because its not
unthinkable that ONE message may have the same header-field
twice or more. Maybe someone thinks that RFC has strict
boundaries, but on the other hand human being do make errors
and so may violate RFCs so wouldn’t it be better to make
dbmail more tolerant for "human-errors" for such a
case?
Just adding the field "id" to that unique key
would solve the issue at once.

What do you think?

Simon

-----Ursprüngliche Nachricht-----
Von: dbmail-bouncesdbmail.org [mailto:dbmail-bouncesdbmail.org] Im Auftrag von Peter Rabbitson
Gesendet: Mittwoch, 5. März 2008 11:02
An: DBMail mailinglist
Betreff: Re: [Dbmail] (patch) Another case of duplicate keys
(via dbmail-smtp)

John Fawcett wrote:
> 
> We can spend time trying to get this to work, but I'm
just wondering
> whether we need to use g_mime_message_set_header at
all. Seeing as
> in the end we must have only one Return-Path header in
the delivered
> message and we are trying to update an existing header,
maybe it
> would be easier to ignore existing return-path headers
and just
> add our own: that way we also avoid duplicate
Return-Path
> headers in the in-memory structure which is the
fundamental issue.
> 

I don't know much about C if anything, but just to chime in.
As far as I 
understand this code deals with general header handling.
Isn't it perfectly 
legal to have several X-headers with absolutely the same
values in a message? 
What happens then?
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Simon Lange wrote:
> What me (duplicate key issue) wonders even more: why
using db-keys without an autoincrement field? This may is
some kind of code-issue but it is definetly also a db-model
issue. What reason the key has no autoincrement field?
> current: UNIQUE KEY `physmessage_id_2`
(`physmessage_id`,`headername_id`,`headervalue`(255))
> well, this cries for a duplicate key error, because its
not unthinkable that ONE message may have the same
header-field twice or more. Maybe someone thinks that RFC
has strict boundaries, but on the other hand human being do
make errors and so may violate RFCs so wouldn’t it be
better to make dbmail more tolerant for
"human-errors" for such a case?
> Just adding the field "id" to that unique key
would solve the issue at once.
> 
> What do you think?

A very old database-design debate.

UNIQUE KEYs are perfectly valid. So are duplicate headers.
Duplicate headers are
*not* inserted more than once. The code is specifically
designed to avoid them.
The fact that it still appears to happen is a bug, not a
faulty design.

Auto-increment integers used as primary keys (also known as
surrogate keys as
opposed to natural keys) are a typical pattern used very
often by database
designers geared to webdevelopment on mysql/php. There are
many reasons to avoid
them where possible

http://en.
wikipedia.org/wiki/Surrogate_key

In this case John Fawcett appears to have tracked this issue
down to a memory
corruption.

-- 
 
____________________________________________________________
____
  Paul Stevens                                      paul at
nfg.nl
  NET FACILITIES GROUP                     GPG/PGP:
1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail