Question Answer Plugin

@angus A custom field would probably be the best option here. Do you store the votes somewhere?

They were being stored as vote post actions, i.e. in the vote_count column.

Would it be possible to delay the deletion of existing vote_count data? Everything else I can work around.

I’ve changed Discourse version to v2.0.2 but still have the same error.

Already checked inside the container and Post.rb model has “vote_count” attribute.

As in you’re using the PostAction model to store the votes on each post? Because if the plugin is, the votes post action would have been nuked upon upgrade. What I’m going to do instead is to ignore the vote_count column for now and remove the migration that drops the post action.

1 Like

Yes

Indeed

Thanks, I’ll update the plugin to migrate any existing vote_counts to custom_fields tomorrow.

After a grace period we can remove the existing vote_count columns.

Hmm the vote count column isn’t the critical one here since you can recalculate it from the post_actions. Unfortunately for @kinto_d, the columns have already been dropped.

There’s probably a ‘history’ record somewhere I can use to reconstitute any lost data for the period the migration was active. I would check now, but I’m sans laptop.

Just in case, we removed the migration in

https://github.com/discourse/discourse/commit/b49c662aa4724b4761927a7ceb31bcda35f9880a

4 Likes

Much appreciated. Will handle the ‘migration’ to custom fields in this plugin asap.

1 Like

Just to say, I had this issue having just rebuilt as part of a domain migration and had Discourse update itself (and plugins, it seems) which was causing a 500 error.

The logs were showing NoMethodError (undefined method vote_count' for NoMethodError (undefined methodvote_count’ for … etc.

Took some time to identify the issue as I thought initially it must be a routing error from the domain migration! That’ll teach me to remember to update plugins first! :flushed:

Ok, an update here. Sorry for the delay, this caught me at an inconvenient time.

I’ve just merged an update that:

  • Updates the plugin to use various custom_fields to store vote data and integrates that into a functionality identical post vote action UX.

  • Migrates existing post vote actions to the new custom_fields.

https://github.com/angusmcleod/discourse-question-answer/commit/257a6c680b8855790ae70b950654f91686e727a8

Example topic: https://discourse.angusmcleod.com.au/t/can-you-solve-aldhelms-lorica/59

This should work seamlessly for anyone who did not upgrade Discourse between these commits:

If you did upgrade Discourse between these commits, after upgrading Discourse and this plugin the QA functionality will work fine, but all votes in existing QA topics will be ‘0’.

The best idea I’ve come up with so far to retrieve vote data for those that upgraded between those commits is to search the production logs for instances of PostAction create, filtering by type and reducing by PostAction destroy (filtered by type). If anyone else has a better idea, let me know.

Rebuilding data from server logs is something of a last ditch effort, but nonetheless if you upgraded in specified period and you’re interested in this solution, please let me know.

3 Likes

After I update the plugin, I can’t delete the question post (including normal post). Does this just happen to me? or does this happen to others too?

Thanks.

Started DELETE "/t/37" for 140.213.20.175 at 2018-07-15 07:26:14 +0000
Processing by TopicsController#destroy as */*
  Parameters: {"context"=>"/t/lounge-tesests/37", "id"=>"37"}
Clearing Active Record cache, this can happen if schema changed while site is running or in a multisite various databases are running different schemas. Consider running rake multisite:migrate.
Completed 500 Internal Server Error in 39ms (ActiveRecord: 14.6ms)
ActiveRecord::StatementInvalid (PG::UndefinedColumn: ERROR:  column "vote_count" of relation "posts" does not exist
LINE 1: ...osts" SET "bookmark_count" = 0, "like_count" = 0, "vote_coun...
                                                             ^
: UPDATE "posts" SET "bookmark_count" = 0, "like_count" = 0, "vote_count" = 0 WHERE "posts"."id" = 59)
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/rack-mini-profiler-1.0.0/lib/patches/db/pg.rb:95:in `exec'
Failed to handle exception in exception app middleware : PG::UndefinedColumn: ERROR:  column "vote_count" of relation "posts" does not exist

You might try a rebuild, especially if you upgraded from the web interface.

What version of the plugin and what version of discourse are you running?

Installed this, pretty nice however it has an issue with the Badge Flairs on the “Sub replies” see below.

Discourse:
v2.1.0.beta2 +422

1 Like

Thanks, now fixed :sun_with_face:

https://github.com/angusmcleod/discourse-question-answer/commit/af4290fa234929bc90db17c629ee7b6b48b7b520

3 Likes

@angus I had the same issue. I am using version 0.2

I reported this as a issue here https://github.com/angusmcleod/discourse-question-answer/issues/9

@sinister89 @kinto_d @barreeeiroo Thanks guys, there was indeed an issue. Should be fixed now. Please update and try again.

3 Likes

@angus is there an easy way to collapse the comments and hide them and give a button which user needs to click to show comments, like in medium?

Thought behind this feature request is that if the comments are too many or too long, then distract the user from the Answers. Quora and Stackoverflow also do some kind of collapsing but that might need more work.

Stackoverlfow

Quora
00%20PM

Yeah, that’s doable. Remind me next Friday and I’ll do it next weekend.

2 Likes