All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

TYPO3 Neos Content Repository

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the TYPO3 Neos-Development (category Neos development team)

Core-5.0 Content Repository

  • Unified data access through one api
  • backend storage drivers for
    • relational databases (complete sql databases with ORM layer?)
    • xml databases (xquery interface)
    • xml file (is also a data store if several nodes of the same type exists on the same level, eg. calendar entries)
    • filesystem (directory structure layout?/could be several drivers for different strategies)
    • memory (interesting for caching, a caching object is just another simple object)
    • ldap accessible data stores (oh yeah, ???)
    • dav (???)
    • soap (???)
  • Inner scalability by using a object mapping system
  • Possibilities with a clean design an layering
    • Pooling of content repositories, means "Content Repository RAID-1" :) yeah, that is fun, load balancing on CR base (maybe academic, but cooool)
    • Staging on CR base :)
  • Strict locking of content!

Object Mapping System

  • Unifies the object id of several data pools for the system
  • Simple table/xml file/... with organizational metadata
    • system(global) ID
    • content repository ID
    • Metadata
      • Date/Time of creation
      • Version (if linear versioning system/no branching)
      • No DC metadata there
  • Workflow informations (is this the right place? do we loose any flexibility? maybe bad for a real flexible sytem?
    • => what is a workflow? a stateful interaction between objects (user/group/role | data object | state/state object)
  • Makes it able to store version 1 of document in storage1, version 2 in storage2
  • Registering a default content repository, maybe another one a later time
    • Scenario to integrate a content repository not available on start
      • Registering data model informations
      • mapping

Metadata System

  • Requirements, clean Dublic Core with language support?

Phase 1

  • Start with an ORM and three different data object types (article,...)

Phase 2

  • Build a first prototype of the object mapping system and request the content through this layer

Phase 3

  • Integrate the first filesystem driver

Phase 4

  • Testing and benchmark system should be available
  • Benchmark raw / orm / cr data access time
  • Start researching/refactoring of the subsystem (we cannot get the speed of the raw acess, but we can speed up "CR over object mapper" to ORM access time)
    • Caching complete query resultsets when working with data objects?
    • Caching complete data objects?
    • Caching is only possible with exclusive data access!


relating projects (edit this, in alphabetical order)