Discussions - Neos Sprint 2015 - Frankfurt

Meeting Notes for “Search” Discussion

Attendants: Johannes Steu, Hans Höchtl, Aske Ertmann, Christian Müller, Sebastian Kurfürst, Dominique Feyer, Daniel Lienert, Markus Goldbeck

Evolving TYPO3CR to contain basic filtering

  • we want to support a default possibility for filtering (based on node properties) and sorting without ElasticSearch or SimpleSearch
    • Aske has suggested to put the Search API in a separate package (TYPO3.TYPO3CR.Search), but make TYPO3CR depend on it for the search APIs.
    • All these packages will be part of the Neos Development Bundle (see below)
    • There should be multiple implementations for this package, a “dumb” one based on MySQL / Postgres (which might be based off SimpleSearch); and a “Full”-Fledged one based on ElasticSearch
    • That means the adapters are the following:
      • “dumb” MySql (NodeBased using Indexing Tables)
      • Elasticsearch
      • SimpleSearch
  • NEXT STEPS
      1. request TYPO3CR.Search queries from people for getting the 80% use cases
      1. MERGE/finalize christophers changes which make cleans up the TYPO3CR NodeData Repository (and Christian also has some changes on the list there?)
      1. create index tables in “Dumb” Search
      1. probably add 1-2 methods to NodeInterface to query nodes
    • Start with implementation in CR (rudimentary)
      • first solid interface
      • querybuilding hidden from the outside
    • 4 (Parallel): Raise Quality for Search packages, by writing behat test for dimensions, workspaces, …
      • Basic idea: have different conformance levels to which implementations can adhere to.

Make Search Packages Official Packages

  • We all agree that searching functionality is vital to the success of a lot of Neos projects.
  • using Node Based CR Search (without ElasticSearch) for simpler Projects. For big projects, people will use ElasticSearch (our assumption)
  • Many people of the team are responsible for the Search packages so far
  • SUGGESTION by all participants: raise quality (by writing tests) and then add these packages to the Neos Development Bundle, effectively making them team-owned packages.
  • For Jira, we propose using an “INCUBATOR” project which should contain packages which we want to become part of the core distributions (Flowpack is already some sort of incubator)
  • -> TYPO3CR.Search will move closer to the core
    • integrate in into the Neos Distribution
    • enhance the quality
    • tests
  • We agree backwards compatibility in the existing search API is crucial; but it might be an option to add a feature flag or so to get “advanced” query results back – in order for a query result to contain aggregations etc.

Search Frontend

  • SearchPlugin becomes Frontend ElasticSearch Plugin
    • will be tailored to ElasticSearch features
    • This package could be taken over by anybody in the community/team who wants to help out; Sebastian would hand over this package (which currently still is at a very rough and prototypical state, anyways)
    • solve rendering stuff
    • integrate complex stuff aggregations
    • aggregations could be configurable with yaml or TypoScript
1 Like