Change the implementation of AttachmentCollection and RecipientCollection to use tables


Due to difficulties with the pstsdk::attachment and pstsdk::recipient classes, a non-standard approach had to be taken to creating an enumeration to iterate over all classes in a given object. This was also true with messages until another solution was found. Attachments originally could not be implemented without a change to the pstsdk itself.

This change from the current implementation to using the underlying tables is important for both stability and speed.
Closed Oct 17, 2010 at 5:17 AM by thoward
Closing as cannot conclusively tie problematic behaviour to this change.


ccurrens wrote Oct 16, 2010 at 12:38 AM

Complete 10/15 - cc

thoward wrote Oct 16, 2010 at 9:58 AM

This seems to have caused some issues. I think we need to revisit this implementation. I'm getting a lot of exceptions thrown trying to retrieve properties like subject, and missing attachment names, etc... Good news: exception handling is working! Bad News: Not sure the table based implementation is super stable yet... Perhaps we're losing references to scope issues?

ccurrens wrote Oct 16, 2010 at 11:41 PM

I've gone through ~1000 messages from different PSTs I have, and haven't run into a single error of any sort. I'm sure it's not the implementation of the table in terms of scope issues, as I'm able to new any variable I need persisting across calls.

I know you were using at one point, you were using a patch build of the pstsdk instead of an official check-in...maybe a change in there is creating a non-related runtime error?

thoward wrote Oct 17, 2010 at 5:16 AM

I took your advice and reverted my local copy of the unmanaged SDk to remove my customizations... But I still see the same behaviour. I'm fairly certain this is data related, but is a combination of problematic data, and a lack of robustness in the unmanaged SDk for various types of data. It seems to me the PST layer, and especially the convenience methods like get_XXX and the sub collection accessors, are not well developed at this time.

I agree that this is not related to your changes, but maybe I never tried this data before. Specifically, I'm using the Enron dataset PSTs for Chris Dorland and a few others, including my own back up PST, etc... Some PSTs work fine, others are riddled with errors. We'll come back to this during testing and see what else we can do to improve user experience.