Re: [Mailman-Developers] New Interface
Harshit Bansal writes:
How can this composability be achieved in a model? I mean that the size of a table is fixed in a model and if a style describes just a partial set of attributes then what would be stored in other attributes?
(1) In a NoSQL database (MongoDB, for example), you can store a partial record with no preparation. This is a good thing and a bad thing, depending on how the now-you-see-them-now-you-don't fields are used.
(2) SQLAlchemy (and the underlying RDBMSes) allow you to have optional fields. This is implemented by storing NULL in the missing field.
Also how would this partial style be applied to a mailing list?
A style would be a list of stylets (NOTE! none of the identifiers below are real! All names have been changed to protect my ignorance!):
s1 = { notmetoo_default: True, nomail_default: False }
s2 = { notmetoo_default: False, ack_default: True }
newstyle = [s1, s2]
def apply_style(style, mlist):
try:
mlist.start_transaction()
for s in style:
# common attributes will overwrite earlier values
mlist.apply_stylet(s)
# make sure all attributes are set to sane values
mlist.validate_style()
mlist.commit_transaction()
except Exception:
mlist.rollback_transaction()> 2: Current 'IStyle' interface allows us to define either a partial
style(stylet, describing just a partial set of attributes) or a complete style. But is that possible with a model?
There should be either an SQLAlchemy option for each attribute to be optional, or maybe the inverse attribute of required. Use that option on the model attributes.
3: If I go for style composabiltiy as described by you then how would I represent that idea in REST and Postorius?
Basically the same way.
Steve's got it right. Just a few other thoughts.
On Jun 06, 2016, at 03:35 PM, Stephen J. Turnbull wrote:
(2) SQLAlchemy (and the underlying RDBMSes) allow you to have optional fields. This is implemented by storing NULL in the missing field.
I think we'd prefer this method, i.e. that the stylets would be stored in the existing database, and we'd use NULLs to indicate that a particular style variable is not set in the stylet. Thus, when that stylet is applied, it would just skip over that attribute.
3: If I go for style composabiltiy as described by you then how would I represent that idea in REST and Postorius?
Basically the same way.
Just sketching things out (IANAWD :)
You'd be able to create new stylets, giving them a name. For each variable in a stylet you'd be able to say whether the variable is enabled or not. If it's not, then the stylet won't change that variable. If it is enabled then it can be set in that stylet.
You probably want to be able to clone and delete stylets too.
You'd then have a second interface which would be for composability. I think you should be able to select named stylets and include them in your style (which would also be named). You'd be able to reorder the stylets in a style, add and remove them from the stack, etc.
Bonus would be to keep track of which styles and/or stylets apply to a particular list so you could do interesting things like:
- find out which lists use(d) a particular style or stylet
- change an existing mailing list by changing a style or stylet (which differs from how things work today.
Of course styles and stylets would be exposed in REST, and we'd have to discuss where those resources live inside the tree. But we can do that later, once/if the basic model sketched out here and in Steve's response ends up making sense.
Cheers, -Barry
participants (2)
-
Barry Warsaw -
Stephen J. Turnbull