firesphere

This would replace a construction like this:

  1. /**
  2.   * Called during construction, this is the method that builds the structure.
  3.   * Used instead of overriding __construct as we have specific execution order - code that has
  4.   * to be run before _and/or_ after this.
  5.   * @throws Exception
  6.   */
  7. public function init()
  8. {
  9. $this->addClass(Message::class);
  10.  
  11. $this->addFulltextField('Title');
  12. $this->addFulltextField('Message');
  13. $this->addFulltextField('Content');
  14. $this->addFulltextField('Channel.Title');
  15. $this->addFulltextField('Channel.SlackId');
  16. $this->addFulltextField('Attachments.Title');
  17. $this->addFulltextField('Attachments.Text');
  18. $this->addFulltextField('Attachments.Fallback');
  19. $this->addFulltextField('Files.Title');
  20. $this->addFulltextField('Files.Preview');
  21. $this->addFulltextField('Files.FileData');
  22. // Filterfields are for faceting :)
  23. $this->addFilterField('UserID');
  24. $this->addFilterField('ChannelID');
  25. $this->addFilterField('WorkspaceID');
  26. // Sort by date
  27. $this->addSortField('FormattedPostdate');
  28. // Boost on relevant content
  29. $this->addBoostedField('Message');
  30. $this->addBoostedField('Attachments.Text');
  31. $this->addBoostedField('Files.Preview');
  32. }
firesphere

Instead of having an init method on your FullTextSearch, this would be a yml. the default should be applied to all classes where possible, the Channel for example, would only be applied if the relation like that exists on the classes defined above. The defaults are grouped, same as the sort fields, to attempt to make them a bit more unified 🙂

firesphere

Any thoughts on if this works for you?

  1. Firesphere\SearchConfig\Services\SolrCoreService:
  2. config:
  3. endpoint:
  4. localhost:
  5. host: 127.0.0.1
  6. port: 8983
  7. core: 'SilverStripe-Users'
  8. classes:
  9. - Firesphere\StripeSlack\Message
  10. fulltext_fields:
  11. fields:
  12. default:
  13. - Title
  14. - Content
  15. - Message
  16. Channel:
  17. - Title
  18. - SlackId
  19. Attachments:
  20. - Title
  21. - Text
  22. - Fallback
  23. Files:
  24. - Title
  25. - Preview
  26. - FileData
  27. filter_fields:
  28. - UserID
  29. - ChannelID
  30. - WorkspaceID
  31. sort_fields:
  32. - FormattedPostdate

Filter fields are indirectly useable as Facet fields. Grouping is to be done, same as filter limits etc., but this is the current state using Solarium on the Slack Archive I'm running. Current state: Pre-alpha at best 🙂

null

@pn, searching Page content for keywords is a very straightforward use-case for what Solr is used for. You could also use FullTextSearch class built into the CMS

pn

Thanks - the application will be hosted on SilverStripe Platform so I will check what using Solr involves

null

on SSP, I think it's an extra charge. Bit of an advantage though, because you're offloading your search capabilities onto another CPU

pn

Yeah, agree - just that it ll need to be signed off and be outside scope of the current project.

firesphere

Does anyone know why Solr would stop returning all fields, despite docs saying it should?

  1. "params":{
  2. "q":"help",
  3. "fl":"*",
  4. "_":"1553237667007"}},
  5. "response":{"numFound":3664,"start":0,"docs":[
  6. {
  7. "_documentid":"3758-Firesphere\\StripeSlack\\Models\\Message-[]",
  8. "ID":3758,
  9. "ClassName":"Firesphere\\StripeSlack\\Models\\Message",
  10. "ClassHierarchy":["Firesphere\\StripeSlack\\Models\\Message"],
  11. "_version_":1627615026553552896},
  12. {

There are a lot more fields in the docs 😞

firesphere

Lots of reasons. If you could solve those reasons, the ops team would be eternally grateful