I'm in the process of adding a voting system system for members to vote on content and am wanting to get some advice.
I have a model for each vote:
public class MemberVote
{
[PrimaryKeyColumn(AutoIncrement = true)]
public int Id { get; set; }
public int ContentId { get; set; }
public int MemberId { get; set; }
public int Vote { get; set; }
}
and am storing these and updating these in the database.
When I get a list of content of the particular document type from the Examine index to display on the page, I'm also wanting to get the votes count for each one, as well as being sort them by this value.
The best way to achieve this that I can think of is each time a vote for the particular content is cast, reindex that content and in the event handler GatheringNodeData event, get the total from the database using sql.
Will this cause too much strain on the server? Are there better ways of doing this?
I understand your desire to have the votes influence order of results, but i dont think its usually good to keep reindexing either not on large indexes, i think it can slow things dow a fair bit. How were you thinking votes would boost a particular content item in your results? This definitely isnt an easy route and is a hack really but maybe you could create a custom search query provider for examine, have a custom db table with just the content id and number of votes. Then when querying apply different levels boosts to the document id field based on votes.
Another possible thing to investigate would be to implement your own icomparer in your orderby. I forget what other properties are available at that point as well as score.
I'd hope if done carefully this may be more performant than reindexing. Other than that schedule your re- indexing rather than after each vote how critical is it that results are 100% up to date each second. Instead store votes and reindex daily.
This particular content which is of just one document type and is over a separate index, is shown in a paged list of 10 or so items at a time, and can be sorted by name, votes, etc. The total votes for each is also shown. It would be important to keep the total votes up to date otherwise it would confuse the voter. What kind issues would occur from reindexing just one node in an index? I can see those other alternatives making the searching slow and resource intensive.
Hopefully someone can contribute that has done more benchmarking with examine, i've just found its quick to query and there is a performance hit from indexing which is usually only noticable with a lot of nodes ,but just something to be aware of if there was a lot of voting going on. You may be ok, there are no other solutions i know of.
Voting system for content nodes
I'm in the process of adding a voting system system for members to vote on content and am wanting to get some advice.
I have a model for each vote:
and am storing these and updating these in the database.
When I get a list of content of the particular document type from the Examine index to display on the page, I'm also wanting to get the votes count for each one, as well as being sort them by this value.
The best way to achieve this that I can think of is each time a vote for the particular content is cast, reindex that content and in the event handler GatheringNodeData event, get the total from the database using sql.
Will this cause too much strain on the server? Are there better ways of doing this?
Sorry for the wall of text!
Hi Mahgo,
I will not recommend reindexing examine on each vote definitely. It can be a problem.
The process of voting can be really long.
It's better to write data to sql and use it from there.
Thanks,
Alex
The main reason to reindex the votes into the index is for sorting and paging with Examine. I'm not sure of any other way to achieve this.
I understand your desire to have the votes influence order of results, but i dont think its usually good to keep reindexing either not on large indexes, i think it can slow things dow a fair bit. How were you thinking votes would boost a particular content item in your results? This definitely isnt an easy route and is a hack really but maybe you could create a custom search query provider for examine, have a custom db table with just the content id and number of votes. Then when querying apply different levels boosts to the document id field based on votes.
Another possible thing to investigate would be to implement your own icomparer in your orderby. I forget what other properties are available at that point as well as score.
I'd hope if done carefully this may be more performant than reindexing. Other than that schedule your re- indexing rather than after each vote how critical is it that results are 100% up to date each second. Instead store votes and reindex daily.
This particular content which is of just one document type and is over a separate index, is shown in a paged list of 10 or so items at a time, and can be sorted by name, votes, etc. The total votes for each is also shown. It would be important to keep the total votes up to date otherwise it would confuse the voter. What kind issues would occur from reindexing just one node in an index? I can see those other alternatives making the searching slow and resource intensive.
Hopefully someone can contribute that has done more benchmarking with examine, i've just found its quick to query and there is a performance hit from indexing which is usually only noticable with a lot of nodes ,but just something to be aware of if there was a lot of voting going on. You may be ok, there are no other solutions i know of.
is working on a reply...