#1 Avoid Serialization with NHibernate

[Brian]

Hi,

I just wanted to make a small note that NMail should avoid serialization in Spool and local store. Ideally, NMail should map out the full class and properties or as a class component.

OR

Avoid using the AssemblyVersion("1.1.*") versioning.

-------------

Because serialization is in place, new release cycles will break existing serialized data inside the database, because .NET serialization includes versioning numbers.

I noticed this issue when I had a spooled email in the spool database, recompiled (which caused a version increment), and re-ran the NMail server. The NMail server Spool thread was stuck in an endless loop trying to create a DeliveryBatch (for the previous spooled email) by trying to get all mails that were filtered=true and progress=false and Host = :Host. Since Host was a serialized object, the database did a binary comparison of both the Host (with the new assembly version number), and Host (with the old assembly version number). Essentially, there was no change to the Host class, only the version number of the assembly changed which effectively, the dataformats were incompatible.

This could be seen as a serious consequence and problem with future releases because if someone were to "upgrade" to a new version, their existing LocalDataStore would not be readable or usable by the upgraded NMail server.

I'd suggest mapping out the entire classes in their full form to avoid serialization. If the object shema changes, then you can simply do a Database Diff with LiquiBase to provide an upgrade solution.

-Brian Chavez