prakhar joshi writes:
> So you want to store only changed attributes under a specific list
> style in the table ? Isn't that make the table dynamic in width as
> sometimes only one attribute is stored and sometimes 3-4 attributes
> are stored ?
That's a feature of object-relational managers (ORM) like SQLAlchemy.
In the background there will be a special value in the backing RDBMS
such as 'inherit' or perhaps NULL. But NULL is risky because it has
assorted interpretations.
> By extensibility you mean to add new attributes ?
Attributes.
> or add new class as there are few classes in the
> mailman/src/mailma/styles/base.py (but that can't be possible
> through web interface, I guess? )
Anything's possible, but Zope's experience with that level of
through-the-web extensibility was pretty bad. We don't need it.
> > { name: <list specific>, read-only: no, notmetoo_default: no }
> > { name: anonymous_overlay, read-only: yes, redact_all_addresses: yes }
> > { name: discussion, read-only: yes, <usual discussion list options ...> }
> >
>
> If there are more than 1 attributes in the last section of above list style
> configuration then the list table will not have the same width ?
I'm not sure what you're asking. Tables have to have the same width
by definition. You use NULLs or other special values to simulate
absence of a value, or a table join with optional attributes in a
separate table. Object-oriented DBs can have different attributes for
each object.
> unspecified attributes ? You mean attributes other than that of mailing
> list table ?
No, I mean the attributes I was too lazy to write in the schematic
example above.
> I think we are still not on same page for list style storage as
> still there are few things that I have in my mind like admin can't
> create its own new attribute, he/she can just change the value of
> the attribute, right ?
Probably. What I had in mind was that site admins could add new
Handlers that define attributes that aren't in the standard set, or
somebody could want to import a style from a later version of Mailman
that has such attributes.
> And if that is true(admin can't add new attributes) than how can we
> just store only changed/modified attributes in the styles table as
> than the table will not have same width, lets assume for style A we
> will store one attributes and for style B we will store two/more
> attribute.
To create attributes on the fly is easy, even in RDBMS. You have a
table user_defined_attributes with columns foreign_key, attribute_id,
and attribute_value. Then do a select on the foreign key.
> Basically the style table will be copy of mailing list table and
> will have same number of column same as mailing list table with one
> more column about permission (read_only or editable).
You need to be more careful about this. I'm not sure exactly how this
is implemented in Mailman 3, but a mailing list has attributes (such
as the owner and the moderator list) that are not relevant to styles.
There is going to be a question of whether to refactor the list schema
into a "stylable" part and a "list-specific" part (so that the
stylable part is literally a copy of the style) or to copy the
individual attributes from styles to the list configuration.
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
