Babble - A Chat Plugin [ARCHIVE]


(Tumi) #755

Ok pls tell me . I want use discourse with MANY of plugin for 200 users online . What is the recomended PC for that? 2 Core ? 4GB ram or 8 GB ram ? 40 SSD or more ?


(Vincent) #756

My only reasonable advice would be to just start with a 1 core/1 Gb plan, stress it, and upgrade accordingly.


(Stephen) #758

Unsure if this has been noted before, but if the first post in a channel is flagged, and that flagged post is deleted, then the channel is deleted with it. We had a user write a test message in a channel then flag it to tidy up…


(James Kiesel) #759

Ah, thanks. Makes sense. I wonder if the best course of action is to disallow flags on the first post of a channel…

(PS I added flags, heh :slight_smile: , but want to wait for a little bit to announce it, with a couple other features I’m working on)


(Stephen Chung) #760

@gdpelican, the following line:

might be breaking Data Explorer when topic_id is serialized for display:

ActiveModel::MissingAttributeError (missing attribute: category_id)

(James Kiesel) #761

Hm, I’d be surprised if that was it; Data Explorer shouldn’t be doing any serializing in it, and the topics table has a category_id on it whether or not it’s serialized…

What’s the query you’re attempting to run in Data Explorer?


(Stephen Chung) #762

Yes Data Explorer serializes certain items for DISPLAY. Among them topics.

The serializer used is BasicTopicSerializer to which you added the catefory_id

There is an error related to missing category_id in topics that causes a query to throw.

Data Explorer never requires category_id

I’m just putting two and two together…


(James Kiesel) #763

Again, can you provide the query you’re running to reproduce the error? That will go a long way towards me figuring out what the problem might be.


(Stephen Chung) #764
Select * from posts

Or

Select * from posts where id=1

(James Kiesel) #765

Cool, I can confirm this, although it doesn’t really have anything to do with Babble; this should be reported as a #bug in Data Explorer as an incompatibility with the plugin method add_to_serializer.

I can manually fix by adding category_id to extra_data_pluck_fields in discourse-data-explorer/plugin.rb#138, so ideally calling add_to_serializer for one of the matching serializers in that method would add the field to the list of plucked fields for that method.

Not sure who the right person to flag here is, maybe @tgxworld?


(Stephen Chung) #766

I concur with your opinion. It will never be certain what field add_to_serializer will add by a plugin. Data Explorer shouldn’t be so brittle to break when a plugin merely adds a field here.


(Angus McLeod) #767

Could it be something to do with uncategorized topics?

I’m not really familiar with what’s going on here, but maybe you could you do something like:

add_to_serializer(:basic_topic, :include_category_id?) { object.respond_to?(:category_id) }

(Stephen Chung) #768

It can’t be, as all my topics are categorized.


(James Kiesel) #769

Data Explorer has a line like this:

pluck_fields ||= {
  topic: { class: Topic, fields: [:id, :title, :slug, :posts_count], serializer: BasicTopicSerializer }
}

which says to me, ‘When I’m using the BasicTopicSerializer, only give me these columns from the database’. Problem is, when I write ‘add_to_serializer’ in my plugin, it changes what columns BasicTopicSerializer needs, which blows this up because that array is hard-coded in Explorer. So the fix is something like extracting those arrays into their own methods, and overriding them when add_to_serializer is called from a plugin. Here’s my magical realism (read: will require more thought to actually make work) implementation:

def self.extra_data_pluck_fields
  @@extra_data_pluck_fields ||= {
    ...
    topic: { class: Topic, fields: pluck_fields[:basic_topic], serializer: BasicTopicSerializer
  }
end
def self.pluck_fields
  @@pluck_fields ||= {
    ...
    basic_topic: [:id, title ... etc]
  }
end
def add_to_serializer(serializer, attr)
  ...
  if DataExplorer.pluck_fields.has_key?(serializer.class.name.to_sym)
    DataExplorer.pluck_fields[serializer] << attr
  end
end

(Stephen Chung) #770

Since Data Explorer is a plugin which may not exist, you probably can’t call on it from the standard plugin API…


(Angus McLeod) #771

hm. Specifically, it fails here, when it tries to use the BasicTopicSerializer on topics from which it has selected those fields: discourse-data-explorer/plugin.rb at master · discourse/discourse-data-explorer · GitHub

I dunno, it seems like adding

add_to_serializer(:basic_topic, :include_category_id?) { object.respond_to?(:category_id) }

in Babble is not a bad fix for this. It seems to fix it on my testing (not in Babble itself, but just by adding :category_id to the basic_topic_serializer in a test plugin, which does indeed repro the error. Using the include seems to fix it.)

A countervailing point here is that you could say that all plugins should expect to be able to use Discourse core as if they were the only plugins in the world. Data Explorer should be able to assume that the basic topic serializer works like it does in core.

But, I see your point.


(James Kiesel) #772

Err, yes. This would be a PR to data-explorer; no change in core is being proposed.

I agree as a workaround, this is the simplest thing, but since it’s not a bug in Babble (and, indeed, will be a problem for other plugins who are modifying serializers which may be used in Data Explorer), it’d be preferable to not have to hack it in this way.

EDIT:
Alternatively, maybe it’s add_to_serializer which should be adding the extra ‘hey should I include this?’ respond_to? check


(Angus McLeod) #773

Yeah, maybe. IIRC it already adds an include? tied to plugin.enabled. It could add to that perhaps.


(James Kiesel) #774

Ah, brilliant, it does accept an option for this. I think that’s the way for now.


(James Kiesel) #775

Alright! Well after all that I’ve proposed a change to core to handle this case: