« Home button
Poll mode
Intrigued by a vB feature »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Poll mode
« Reply #15, on March 8th, 2012, 08:42 PM »
Sure it's already recorded, it just needs displaying.

Regarding vB, it is similar to SMF/Wedge, just you have different coloured bars, one bar red, one purple, one blue etc. All I'm saying is to add classes to differentiate the bars, for style purposes.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Poll mode
« Reply #16, on March 8th, 2012, 08:54 PM »
Oh... I see. I didn't read that through :P
I guess it makes sense indeed. Not in the default skin though ;)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Poll mode
« Reply #17, on March 8th, 2012, 09:00 PM »
Oh I didn't expect the default skin to do that, just  have the classes to support it ;)

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Poll mode
« Reply #18, on March 8th, 2012, 09:20 PM »
We should make sure these classes are set on the list items, not the bar divs :)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Poll mode
« Reply #19, on March 8th, 2012, 09:26 PM »
As long as it lets me style the bars like I'm suggesting, it's all good.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Poll mode
« Reply #20, on March 10th, 2012, 12:00 PM »
I'm looking into adding support for multiple polls right now.

A few things.
- I can either add an id_topic to the poll table, or allow for comma-separated poll IDs in the topic table (or both!) What do you like best? The table solution simply requires adding an extra key (on id_topic), seems simple enough. The poll ID list should be okay too, in the sense that when in Display, we can easily query for the poll details by using id_poll IN ({string:poll_ids}).
- I noticed that poll questions are limited in size -- varchar(255). I *think* it might make sense to make that size larger, for specific cases... Maybe even a varchar(65535) would be okay (or just varchar(20000) to account for UTF8, or whatever...)
Heck, if you look into the database structure, there are dozens of varchar(255) that could really benefit from being switched to a larger size, now that we're requiring MySQL > 5.0.3 anyway... Thing is, it's best to do it now. We could still add some sort of converter to the upgrader code when we release new versions, but it's simpler now.

Oh, and while I'm at it... Maybe we could do without the upgrade script? Maybe we could have it inside the admin area... And call it automatically if we find out that the current database version is different from the current Wedge files version. Ask for users to fill in their admin password, and launch the upgrade process... Thus, no files to remove after the upgrade.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Poll mode
« Reply #21, on March 10th, 2012, 12:09 PM »
Quote
- I can either add an id_topic to the poll table, or allow for comma-separated poll IDs in the topic table (or both!) What do you like best? The table solution simply requires adding an extra key (on id_topic), seems simple enough. The poll ID list should be okay too, in the sense that when in Display, we can easily query for the poll details by using id_poll IN ({string:poll_ids}).
Add an id_topic to the poll table (with key as suggested) and repurpose the existing id_poll field as a tinyint to say whether or not there is a poll attached to the current topic. It's the fastest way of dealing with this.
Quote
I noticed that poll questions are limited in size -- varchar(255). I *think* it might make sense to make that size larger, for specific cases...
I've never verified this, but my reading of the rather-vague documentation in MySQL suggests that when using UTF-8 that's actually storing UTF-8 characters, you store them based on the actual number of characters, not the number of bytes. (Certainly it makes reference to CHAR(10) fields in UTF-8 tables taking 30 bytes, as it has to account for 3 bytes per character) This suggests we'd still end up with 255 characters' worth of question even when using multibyte characters, but this needs verification to be sure.
Quote
Heck, if you look into the database structure, there are dozens of varchar(255) that could really benefit from being switched to a larger size, now that we're requiring MySQL > 5.0.3 anyway...
There's a world of difference between 'could really benefit' and 'might be useful', and actually the only ones that stand out in my head as being useful are things like the topic subject. I'm not sure that most fields which are varchar(255) would actually benefit.
Quote
Oh, and while I'm at it... Maybe we could do without the upgrade script?
Interesting idea, though I'm not worried about it at present, that's what beta is for, right? :P

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Poll mode
« Reply #22, on March 10th, 2012, 10:28 PM »
Quote from Arantor on March 10th, 2012, 12:09 PM
Quote
- I can either add an id_topic to the poll table, or allow for comma-separated poll IDs in the topic table (or both!) What do you like best? The table solution simply requires adding an extra key (on id_topic), seems simple enough. The poll ID list should be okay too, in the sense that when in Display, we can easily query for the poll details by using id_poll IN ({string:poll_ids}).
Add an id_topic to the poll table (with key as suggested) and repurpose the existing id_poll field as a tinyint to say whether or not there is a poll attached to the current topic. It's the fastest way of dealing with this.
I thought that having a 0/1 choice only in a key was going to hurt performance..? Like t.approved?
Quote
I've never verified this, but my reading of the rather-vague documentation in MySQL suggests that when using UTF-8 that's actually storing UTF-8 characters, you store them based on the actual number of characters, not the number of bytes. (Certainly it makes reference to CHAR(10) fields in UTF-8 tables taking 30 bytes, as it has to account for 3 bytes per character) This suggests we'd still end up with 255 characters' worth of question even when using multibyte characters, but this needs verification to be sure.
The MySQL documentation tends to contradict itself on this.
http://dev.mysql.com/doc/refman/5.0/en/string-type-overview.html#id804512 (i.e. VARCHAR(255) allows for 255 *bytes*, not chars)
http://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html (implies otherwise in the first VARCHAR example.)
I guess it would need testing...
Quote
There's a world of difference between 'could really benefit' and 'might be useful', and actually the only ones that stand out in my head as being useful are things like the topic subject. I'm not sure that most fields which are varchar(255) would actually benefit.
Plenty that I could think of when seeing the list, really...
Quote
Interesting idea, though I'm not worried about it at present, that's what beta is for, right? :P
I guess so... But it can also be used during beta!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Poll mode
« Reply #23, on March 10th, 2012, 10:42 PM »
Quote
I thought that having a 0/1 choice only in a key was going to hurt performance..? Like t.approved?
That's the thing, it's not something we put a key on. The flag is simply to identify whether or not we do a second query to get the extra polls or not - if the flag is empty when we get the topic's info, we know we don't have to load a poll or anything, but if it's not empty, we know we have more work to do.

In terms of indexing, we never query based on 'has poll/has no poll' so it doesn't need to be added to any of the indexes on the topics table.
Quote
The MySQL documentation tends to contradict itself on this.
Actually it doesn't. The VARCHAR() is defined as the character length of the string, but internally uses the extra byte(s) to indicate byte length - since character length and byte length are not necessarily joined, it has to know the byte length in order to work out where the row is. The 65535 limit is a hard limit - but only because a MyISAM table is only permitted to have 65535 bytes per row, not for any other reason.

In our case, VARCHAR(255) means 255 characters but that it will probably need a 2 byte length in UTF-8 because 129 Japanese characters, for example, will overflow 255 bytes in physical length.

This is ultimately where the performance penalty of using UTF-8 comes in, where you're expressly not using a single byte character set where you don't have to worry about byte length vs character length.
Quote
Plenty that I could think of when seeing the list, really...
Such as?
« Home button
Intrigued by a vB feature »