On 11/21/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
A couple thoughts ... 1. Is this really something that needs to be controllable at the individual weblog level? or is this something that should be set once by the site administrator and applied to all weblogs? In my mind this is something that most bloggers don't want to think about or deal with, so they'd prefer that someone sets a reasonable default and be done with it. I wouldn't imagine most bloggers wanting to change their linksPerComment value from the default of 25 down to say 15. I think a far more simplified approach would be to just allow these settings at the site-wide level so that individual bloggers don't have to deal with it.
Good feedback. Site-wide works for me. 2. On a separate note, this proposal also brings to mind a generalized
concern that the website table may be growing too big. there are already a lot of properties in that table and undoubtedly it will continue to grow, so should we think of a possible alternative way of expanding on weblog properties? In particular, in expanding on properties like the ones suggested in this proposal which are non-associative and non-constraining (meaning they wouldn't be used in the where clause of a select for example). I was thinking that something like the roller_properties table would work nicely, so it would work like a hashtable and either the key would be websiteid:name or it would be a 3 column table including name, value, websiteid. In either case the nice thing about this is that it allows us to easily add new properties without continually having to alter the schema of the website table. It would also keep the website table smaller and focused on managing the key data about a weblog and it's foreign key associations, instead of the various properties which are often only used in one or two specific places in the app. If we do create this weblog_properties table then we can still use use the properties through the WebsiteData object, the difference would just be that calling setProperty() would modify the properties hashtable and calling getProperty() would get it from the hashtable instead of being a typical attribute. In some cases this may actually make things faster because a query for a weblog from the db won't have to return so much data and instead that data can be fetched lazily when needed. Anyways, something to think about.
Yes, I've always wanted to that. I don't think I have time for it in 3.2time-frame tho. - Dave
