On Wed, Jun 19, 2019, at 9:28 AM, Mark Sapiro wrote:
On 6/19/19 9:11 AM, Abhilash Raj wrote:
Storing list of tuples in database might be inefficient for reads. I don't think there is an accurate column type one could use for this purpose unless we convert them to string back and forth.
If we use PickleType, SQLAlchemy does the (un)pickling for us.
I will read more on PickeType, but I feel like it might not be a great idea to store binary blobs in database. Querying them might get too expensive as SQLAlcmey might have to load all rows in memory, de-serialize them and then do the comparison. But that's my guess, I'll read up.
I suggested going with Member because it comes close to what we require, although memberships can include Users along with addresses which may not be great.
It looks like now there is a need for a BounceInfo model then which could be used to store the information instead of a list of tuples. It could keep the following attributes:
- Address (relationship -> Address)
- MailingList (relationship -> MailingList)
- last_bounce (datetime)
- last_notice (datetime)
- remaining_notices (int)
- total_notices_sent (int)
I am not sure if the bounce score of an address is calculated per-address or is global regardless of a MailingList in Mailman 2.
If it is global, then the score could be stored in Address table, otherwise BounceInfo table.
My idea is scores should be local, i.e. per list. In MM 2.1 there is no such thing as global bounce information/score. Everything is per list and there is no connection between a member of one list and a member of another even if the addresses are the same.
That makes sense, thanks for explanation!
-- thanks, Abhilash Raj (maxking)