paul at nfg
Oct 13, 2009, 1:34 AM
Post #5 of 5
(892 views)
Permalink
|
Denis Frère wrote:
> 2009/10/12 Paul J Stevens <paul [at] nfg <mailto:paul [at] nfg>>
>
> Michael Monnerie wrote:
> >> My question is : can I add columns to DBmail tables without
> breaking something in DBmail ?
> >
> > Yes, I did so for my extensions to have domains and customers in
> it’s own tables. I also modified the aliases table without problems.
>
> Dbmail tries very hard not assume anything about order of fields in a
> table. All columns are retrieved explicitely. So no 'select *' but
> always 'select field1,field2...'.
>
>
> Thank you. That's what I wanted to read. :-)
>
>
> Building a ORM mapping for dbmail is valid for all tables, *except* for
> message retrieval. That is, it'll work in 2.2 (for messageblks), but in
> 2.3 it is no longer a simple query.
>
>
> :-/
>
> Any pointer to that info ?
I explained some of this on the -dev list only two days ago.
I assume you already understand how users contain mailboxes which
contain messages which are pointers to physmessages. I'm talking here
about how raw message data is stored.
Basically, messages are decontructed recursively into their constituent
mimeparts. No decoding or unpacking of mime bodies is attempted. The
mimepart header and body blobs are stored as single-instance atoms. That
is: a unique blob is never stored more than once.
The location and depth of a blob in a particular message (physmessage)
is stored in the partlists table. The blobs themselves are stored in
mimeparts.
A plain/text rfc822 message will consist of two mimeparts, like the good
old messageblks storage.
1: rfc822 headers
2: rfc822 body
A message/rfc822 would result in:
1: rfc822 headers
2: mimepart headers
3: mimepart body
A multipart message with only one mimepart will result in at least 5
mimeparts:
1: rfc822 headers
2: multipart preface
3: mimepart headers
4: mimepart body
5: multipart postface
When a message/* or multipart/* message is stored, the mime-boundary is
thrown away. Such boundaries are transient in that they are not an
integral part of the container, nor of the sub-parts. Boundaries are
only remembered as part of the Content-type header of the containers.
These mime-boundaries are later added back again during message
retrieval, so no information is lost, and message integrity is maintained.
Since the storage model for dbmail has become increasingly intricate
over the years, I decided last year to start working on a dbmail-httpd
daemon that will expose the storage model through a REST-ful interface.
I'll publish that code later this week.
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmail [at] dbmail
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
|
