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

Multiple persistence backends

From TYPO3Wiki
Jump to: navigation, search

This is a page to collect ideas about using multiple persistence backends in Flow at the same time.

I think injecting different PersistenceManager implementations/instances for different connections would be not that big a problem. Maybe we could start with that. Biggest problem I see are queries that would require a join over different connections, which we cannot do of course. So I would do that only in a second step and look at seperated data first.

Ideas (brainstorming)

  1. Manage permission with MySQL and Other resources as news in a NoSQL
  2. A caching mechanism in a DB that is highly optimized to store the cache, but is separate from the main content tree in a MySQL db.
  3. A TYPO3 website has a variety of branches. One of those branches is dedicated to a physical publication, like a magazine. That magazine is produced in XML and stored in an XML DB like MarkLogic or BaseX. I want to have that segment of the TYPO3 tree pull data from the XML DB. and the rest can be stored in the MySQL db. So, a sharded tree approach where one branch of the Content Tree is in one DB, and another branch in another DB.
  4. Use content from legacy DBs, or DBs created by other programs, within a Flow app, but store new content in a Flow managed DB.
  5. Treat other storage mechanisms as an additional persistence layer for some content:
    • Google Drive, iCloud, DropBox, or some custom CDN could be treated as a special kind of DB, a DB of resources.
    • Or, perhaps you could interact with multiple DB clouds, one on Google Apps and another on Amazon...
    • Or, you could interact with 3rd party websites/dbs from within the app as if they were a persistence layer (including, perhaps, a government census db, or a publicly available genealogy/family history db, or some other set of data that is publicly available like ). That would let you interact with some APIs as though they were a DB.
  6. The new TER[1] might use a Triple Store for semantic data - A persistence layer that makes it easy to interact with a Triple Store would be great. The Artififact Repository sends RDF Triples to the Store, and the Artifact Repository Frontend would query the Store with SPARQL Queries. Maybe a semantic persistence layer would enable TER to share a domain model between Frontend and Repository.

Workarounds and recipes

Doctrine itself doesn't care about having multiple instances of it's EntityManager, each with it's own DB connection. You can create as many EntityManager instances as you like. Flow just doesn't support that out of the box, as we treat the PersistenceManager as a singleton.

Word on the street has it, that it is possible to use (inject) the Doctrine-Persistence Layer (\Doctrine\Common\Persistence\ObjectManager) directly instead of the Flow persistence (if you don't mix both).