Forgot to mention that these can be saved in the same solr core as all the artifacts. Just continue to follow the `Artifact.index()` naming conventions like suffixes for type. Use the same names when possible like url_s and project_id_s, and especially make sure to set `type_s` so that can continue to be our primary way to distinguish record types.
--- ** [tickets:#7257] Index all projects in solr** **Status:** open **Milestone:** forge-backlog **Labels:** 42cc **Created:** Fri Mar 07, 2014 09:02 PM UTC by Dave Brondsema **Last Updated:** Fri Mar 07, 2014 09:02 PM UTC **Owner:** nobody Projects should be indexed into solr. They are not artifacts, but they should gain methods like `index` and `index_id` that are used on artifacts, so a similar pattern is used. Put in a reasonable set of fields of top-level project data that would be useful in searches (name, neighborhood, descr, labels, categories, reg date, etc). (Use-cases for this later will be an admin search page for projects, and also a public project directory) Also add a method to ProjectRegistrationProvider so that those extensions can add more fields to what gets indexed. Provide a default empty method so that existing providers don't have to be changed. Include good docstrings for Project.index and the ProjectRegistrationProvider method. After project changes occur that would affect the indexed fields, fire off a background task to update the index for the project. (Somewhat similar to the `add_artifacts` task but much much simpler since artifact references aren't applicable here.) Create a ScriptTask to index all the projects. Use `utils.chunked_find` for the loop. Batch up the solr calls in convenient chunks too, so many documents get sent to solr at once. We will do this later for Users, too, following a very similar pattern, so make new logic a little bit generic so it can be re-used then. Example: background task to add to solr could work for any non-artifact object that has an `index()` method. --- Sent from sourceforge.net because allura-dev@incubator.apache.org is subscribed to https://sourceforge.net/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
