---
** [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.
