Certain plugins need the ability to “preload” data in the topic list. Some specific examples: Discourse solved adds an icon on the topic list when a topic is solved Discourse assign will display the username the topic is assigned to on the topic list To achieve that we have 2 mechanisms: Preloading a custom field If you have any custom fields you need for rendering of the topic list use: TopicList.preloaded_custom_fields << "my_custom_field" This will force the system to ensure that the Topic object model has the custom field loaded when serializing. If you do not do that and try to access a custom field an error will be raised. ###Preloading custom data In some cases you may need to preload custom data that goes beyond a custom field. To do so: TopicList.on_preload do |topics, topic_list| # your custom code to load up all topic data in bulk goes here end This is useful when you need to reach out and preload other models. By carefully using both these methods you can ensure your plugin does not cause N+1 queries.

I believe Feature Voting plugin currently has n+1 queries and perhaps for the same reasons?

very possible, I only added the ability to preload custom data today.

This will make a lot of plugins use way less code, like my signatures plugin.

Does signature show up in topic list? scary …

[imagem] sam: Does signature show up in topic list? scary … Oh no, misread as post list. :smile: Will there be an analogous feature to the post stream?

I would be happy to add an analogous feature, makes sense there as well.

[imagem] codinghorror: I believe Feature Voting plugin currently has n+1 queries It used to. I think I’ve cleaned most of those up. I don’t know of any others. https://github.com/discourse/discourse-feature-voting/commit/135eaf8a5ec0e37b64adf10971384ee88abec580 [imagem] codinghorror: and perhaps for the same reasons? I had to preload the custom fields due to errors if the data was blank. It was tricky to debug at first because I had existing data so I couldn’t replicate the errors reported. Then someone mentioned this process in Babble. Once I implemented it, the errors were gone. I never looked into it further than that.

Just for anyone reading this in 2025 I’ve written an updated version on the same topic [imagem] Preloading data and dealing with N+1 Query problems Developers When working with the Discourse rails application, whether building a plugin, or making a pull request to discourse/discourse there are a number of contexts where you’ll encounter N+1 query problems. This topic explains how to handle data preloading to address such problems and keep Discourse performant. N+1 Query Problems in Rails First, if you’re not already familiar with N+1 query problems, and how Rails addresses them, check out this section of the guides. Topics The N+1 issues to look ou…

Pré-carregando dados e campos personalizados na lista de tópicos

Dev

angus (Angus McLeod) 17 Janeiro , 2025 15:36 9

Apenas para quem estiver lendo isto em 2025, escrevi uma versão atualizada sobre o mesmo tópico

Tópico		Respostas	Vistas
Preloading data and dealing with N+1 Query problems Developers	0	230	17 Janeiro , 2025
The plugin shows HasCustomFields::NotPreloadedError Development	0	97	9 Outubro , 2024
Retrieve Topics based on custom field? Development	12	2182	17 Março , 2022
Fetch third party data for topic list Development	7	308	13 Agosto , 2024
Error with categories with limited visibility and/or subcategories Bug	15	1206	2 Novembro , 2023

Pré-carregando dados e campos personalizados na lista de tópicos

Related topics