Parece que PluginStore sería la forma más sencilla para que implemente recordar los IDs de los hilos de Slack para respuestas en hilo, pero noto que el único uso que tiene en todo discourse-chat-integration está huérfano; nada utiliza realmente el valor que se consulta.
¿Esto significa que está deprecado o simplemente que se está haciendo de otra manera?
Yo solo almacenaría un valor como máximo por tema, así que, considerando todo, esto parece tener una cardinalidad relativamente baja. ¿Es esto razonable para PluginStore?
Si estás almacenando hasta un valor por tema, usar un campo personalizado de tema podría ser mejor para este caso de uso.
PluginStore es un almacén simple de pares clave-valor (KV) que se utiliza en plugins donde la cardinalidad de los datos hace que no sea adecuado para las tablas de campos personalizados existentes. En los últimos años, estamos migrando los plugins a sus propias tablas para obtener una mayor fiabilidad de los datos cuando tiene sentido, como hicimos con el plugin de encuestas. Aún puedes usarlo si tiene sentido para tu caso de uso.
Gracias, suena como que debería hacerlo. Como soy nuevo aquí, ¿hay alguna posibilidad de que me des un ejemplo de un campo personalizado de tema en un plugin para que pueda aprender sin ser una molestia?
Para la siguiente persona que sea nueva en esto y encuentre esto, algunos de los errores que cometí como alguien completamente nuevo en Ruby on Rails:
Pensé que isolate_namespace era parte del patrón a copiar y no me di cuenta de que el namespace al que se refiere es el namespace de la ruta, nada en la base de datos. Esto me causó problemas.
Establecer el campo personalizado no lo guarda. Puedes guardar el objeto del que forma parte (por ejemplo, topic.save!) o solo los campos personalizados (por ejemplo, topic.save_custom_fields)
Podemos ver cómo eliminaremos a largo plazo tanto la tienda de plugins como los campos personalizados, sustituyéndolos o modificándolos con un sistema mucho más restringido y controlado, ya que causan más problemas de los que ayudan.
El único lugar donde usamos campos personalizados y realmente los necesitamos hoy en día es para indicar a los serializadores que existe información “especial” en una publicación o, en casos excepcionales, cuando se están decorando el 50% de las publicaciones del sistema, también se almacenarían datos allí.
Los campos personalizados son demasiado flexibles y tienen muchos problemas de concurrencia.
La mejor manera de agregar datos ricos es que un plugin cree las tablas que necesita y de las que es propietario; esto debería ser lo primero que hagas. Si te encuentras atascado debido a problemas de N+1 u otros, entonces recurre a los campos personalizados para ayudar a evitarlos.
¿Cómo sueles crear modelos y migraciones para los plugins? ¿Usas el generador principal de Rails y los copias a la carpeta del plugin? He creado un generador de modelos y migraciones que añade un prefijo específico del plugin. GitHub - spirobel/discourse at plugin_model_and_migrations · GitHub Quizás sea útil para otros también.
Recomiendo que consulten discourse-policy y el plugin de encuestas para ver algunos ejemplos de cómo realizamos las migraciones. Ese es el patrón que deben seguir.
El cambio se implementará con el tiempo y ofreceremos orientación. El sistema actual, que depende en gran medida de la tienda de complementos y de los campos personalizados, ha dado lugar a innumerables problemas semanales habituales.
Revisé el plugin de encuestas y, basándome en él, creé un generador de modelos para plugins y también este generador de migraciones:
Si entendí correctamente, una de las razones por las que se creó el pluginstore fue la preocupación de que, si los plugins creaban sus propias tablas, los nombres podrían entrar en conflicto. Los generadores que creé antepondrán el nombre del plugin a los nombres de los modelos y las migraciones. Principalmente creé estos generadores porque las migraciones necesitan llevar este número de fecha al principio para establecer un orden predecible. Por eso no quise crearlas manualmente.
Aunque el conflicto es teóricamente un problema, no fue la principal motivación. La gran motivación era que no estaba del todo claro cómo ejecutar las migraciones y queríamos algo con muy poca fricción. Hoy en día, crear migraciones en los plugins es trivial; simplemente debes crear un archivo en la carpeta de migraciones.
De todos modos, los conflictos aún pueden ocurrir con los campos personalizados de las publicaciones.
