Counting votes for Polls

[unibrew]

Hello :)

I'd like to ask for advice in chosing the right sollution. My problem is connected with making PollPortlet task (http://jira.jboss.com/jira/browse/JBLAB-407).

It would be cool to know who has voted on each poll and how many times. This causes that a lot of data will have to be kept and available for very frequent changes.

Obviously keeping that in xml even with use of forge cache wouldn't be any sollution. That is why the only sollution which I can think of is keeping this data in database. EJB3 would be used as the way to change the data.

My question is if it is best sollution or you can give some other better? If it is ok, maybe you could give me some advice on how to make it the best :).

Thanks a lot in advance! :)

[szimano]

Database ? Which database :) ?

I don't get why you're not going to use shotoku...

T.

[dsicore]

Well.. I think we *are* going to use Shotoku. The question is, how do we map some of these things to actual users. I mean, every time a node in shotoku is updated by a user, we will need to keep track of "information" associated with the actions on that node: i.e., answering a poll, adding a wiki page, posting a forum message.

Right now, we have basic user functionality from Shotoku and we need to make sure that whatever we do is useful to all of the above scenarios. The only place we've started storing user information in Shotoku is in the primates portlet. We'll probably just enhance that functionality a bit more and add to it... at least... keeping a users "whuffie" and such there.

The poll system will need to reference that "users points system". So, I think Kozmik's concern here is valid. What we need from you Tomek, is how do you expect to be able to update users' "credits" when they add content to a wiki page?

Whichever way you do this, we will need to do it the same for each application that references users on Labs.

[adamw]

Hello,
I think that the base of user management system - storing usernames, passwords, user <-> role relationships fits best to a DB. Of course, in Shotoku we can store any portlet-related information. An example of how it can be done: there would be a special "users" folder, in it one file per user (named, "username" or sth equally original ;)). I can't think of any special content of this file, but any user information could be stored as properties - for example, his "wuffie" points. There would of course be a helper "User" class and things like that.
That's one way. The other - storing what users, voted, for example in a poll, would have to be stored in some other way ... but that could be quite portlet-specific. One idea - to store one file per poll, in it usernames of those who voted. Here too, there could be a helper class.
So, what do you think? :).

--
Cheers,
Adam

[unibrew]

Hello again
and thanks all for joinging the discussion :-)

I like Adam's *the other way* idea of keeping one file per each poll containing how and who has voted on this poll.
However I must ask if this will be enoughly efficient or what is even more worrying is keeping all objects for those polls' files in cache will be ok? *How big is cache? ;-)*
Every poll file would have to contain list of users and counters for their positive and negative votes. I don't know how many users are there but those files can become quite big. Or not? :)

Cheers,
Rysiek

[adamw]

"unibrew" wrote:

However I must ask if this will be enoughly efficient or what is even more worrying is keeping all objects for those polls' files in cache will be ok? *How big is cache? ;-)*

Well ... you don't have to store it all in the cache. Nobody forces you to. Certainly, you don't have to store all user<->votes info in the cache. Anyway, the information on who voted for what has to be stored somehow, and if there are a lot of voters it will be big no matter how you store it. What can be a problem, is checking if a user has voted. Looking for his username in the file doesn't seem a good solution.

Maybe - it could be done by properties. For each user that has voted, a property would be set (property name = user name), with a +1, -1 content.

The only question is, how efficiently are properties programmed in subversion (for example, are they stored in a tree structure, or a list?), and how many of these can a file have.

[unibrew]

Even more questions not many answers :D

Well ... you don't have to store it all in the cache. Nobody forces you to. Certainly, you don't have to store all user<->votes info in the cache. Anyway, the information on who voted for what has to be stored somehow, and if there are a lot of voters it will be big no matter how you store it.

Yup, I don't have to store all polls objects in cache as a workaround I could keep one object which would cache votes for all polls (List<Poll,List>). It would be empty at the beggining and slowly polls and users' votes would be added and when this object would become *big* (some criterium on amout of the votes or users would be made) I would have to store votes to files and make new empty object.

BUT if I would like to display in poll who has voted and how many times I would have to open the file to get overall scores each time somebody visits the results view of poll portlet becouse in cache object I wouldn't have enough information. :-/

Maybe - it could be done by properties. For each user that has voted, a property would be set (property name = user name), with a +1, -1 content.

Yes using *.properites files can be very good sollution but if the key would be the value would have to be concateneted string of ,. I don't know how fast it will be then to parse those values but probably it will be faster then parsing it from xml I guess. :-)

Rysiek

[adamw]

"unibrew" wrote:
Even more questions not many answers :D

Yup, I don't have to store all polls objects in cache as a workaround I could keep one object which would cache votes for all polls (List<Poll,List<Users>>). It would be empty at the beggining and slowly polls and users' votes would be added and when this object would become *big* (some criterium on amout of the votes or users would be made) I would have to store votes to files and make new empty object.

Something like that, or you can always make an evicting cache (LRU?) ;).

"unibrew" wrote:
Yes using *.properites files can be very good sollution but if the key would be <username> the value would have to be concateneted string of <positiveVotes>,<negativeVotes>. I don't know how fast it will be then to parse those values but probably it will be faster then parsing it from xml I guess. :-)

No no ... no *.properties files. For each node in Shotoku, you can set properties by the node.setProperty(...) and node.getProperty(...) function. These correspond to subversion properties of files and directories (like, for example, svn:ignore). Now, my original thought was, to set propreties on the poll file: one username, one property. And a user can vote only +1 or -1 in a poll, never both.

[unibrew]

Cool I like the svn properties idea. I couldn't find out how the properties are stored tree or list or whatever but I found out about cool feature.

We should note that, as with other svn subcommands, those related to properties can act on multiple paths at once. This enables you to modify properties on whole sets of files with a single command. For example, we could have done:

$ svn propset copyright '(c) 2002 Red-Bean Software' calc/*
property 'copyright' set on 'calc/Makefile'
property 'copyright' set on 'calc/button.c'
property 'copyright' set on 'calc/integer.c'

Shotoku is implementing it? I might be useful...:)

If it would be quite fast I wouldn't have to even cache the votes and then save them to properties at node watchers update. If someone votes I simply change the property. Nothing to cache :). How do you feel about this? :)

Btw, I noticed that those files will be empty LOL, becouse it shouldn't be those files added by project leaders in their directories...it could provoke somebody to lets say tune the results :). That is why I will have somewhere empty files with svn properties... :-)

Cheers
Rysiek

[adamw]

"unibrew" wrote:
Cool I like the svn properties idea. I couldn't find out how the properties are stored tree or list or whatever but I found out about cool feature.

We need to get this information :)

We should note that, as with other svn subcommands, those related to properties can act on multiple paths at once. This enables you to modify properties on whole sets of files with a single command. For example, we could have done:

$ svn propset copyright '(c) 2002 Red-Bean Software' calc/*
property 'copyright' set on 'calc/Makefile'
property 'copyright' set on 'calc/button.c'
property 'copyright' set on 'calc/integer.c'

Shotoku is implementing it? I might be useful...:)

[adamw]

As I phpbb doesn't like quotes-in-quotes.

Anyway, the rest of my post was:

Shotoku is implementing it? I might be useful...:)

Shotoku doesn't support any wildcard opertaions. What would it be useful for?

[unibrew]

This wildcart stuff wouldn't be useful for me but I thought about it teoretically that in some situation it could be cool to set some property on all files in directory without iterating...nothing special.

This Polls subject takes to long, lets find some final sollution... ;)

I couldn't find out on subversion page how the properties are kept. Although I found it in a different way, clever :P. I opened one of the catalogues which svn looks after and opened the .svn directory. Inside it is "props" directory where are text files each for each file in versioned catalogue and there are written those props. I don't think so that using svn props can be in any way faster than keeping properties in normal *.properties files, sadly.

Keeping user=vote pairs in properties files for voting itself isn't so bad at all. When I show the main Poll view I don't have to read this file even becouse I can leave voting buttons and if someone will try to vote second time, then I open a file and tell him what I think about it :P.

Would that be enoughly efficient? There won't be so many votes I think because of the fact that one user can vote on poll only once.

Another thing are some global poll statistics but that can be kept in object(would contain statistics for all polls) in cache apart from the properties files.

I have written much...:-/ but I want to come to the sollution and start coding :-)

Thanks for helping me :D

[adamw]

"unibrew" wrote:

This Polls subject takes to long, lets find some final sollution... ;)

Then write a proposed solution here :).

"unibrew" wrote:

I couldn't find out on subversion page how the properties are kept. Although I found it in a different way, clever :P. I opened one of the catalogues which svn looks after and opened the .svn directory. Inside it is "props" directory where are text files each for each file in versioned catalogue and there are written those props. I don't think so that using svn props can be in any way faster than keeping properties in normal *.properties files, sadly.

So, if you would want to check if a user voted in a poll, you would have to query the "poll file" if a property with this user's name is set. This wouldn't be so fast, if the poll reached for ex. 10 000 voters ;). But then, that's unlikely. And voting doesn't happen often, so I think it's acceptable.

"unibrew" wrote:

Keeping user=vote pairs in properties files for voting itself isn't so bad at all. When I show the main Poll view I don't have to read this file even becouse I can leave voting buttons and if someone will try to vote second time, then I open a file and tell him what I think about it :P.

I would rather think of keeping votes as: property name = username, property value = +1 or -1. And a special property with the global results (or, this can go to the file content).

"unibrew" wrote:

Would that be enoughly efficient? There won't be so many votes I think because of the fact that one user can vote on poll only once.

I think so :).