mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
[PR #580] [WIP] Second level cache #8403
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Original Pull Request: https://github.com/doctrine/orm/pull/580
State: closed
Merged: No
Hi guys. :)
After a look into some implementations I end up with the following solution for the second level cache..
There is lot of work todo before merge it, but i'd like to get your thoughts before i go any further on this approach.
I hope my drafts are good enough to explain the idea :
Cache strategies
classes / interfaces
Defines a contract for accessing a entity/collection data cache. (Doesn’t employ any locks)
Defines contract for concurrently managed data region. (Locks the data before update/delete.)
Defines entity / collection key to be stored in the cache region.
Build cache entries and rebuild entities/colection from cache
Factory from second level cache components
Collection Caching
The most common use case is to cache entities. But we can also cache relationships.
A “collection cache” caches the primary keys of entities that are members of a collection (OneToMany/ManyToMany).
and each element will be cached into its region.
Only identifiers will be cached for collection. When a collection is read from the second level cache it will create proxies based on the cached identifiers, if the application needs to access an element, Doctrine will go to the cache to load the element data.
Query Cache
The query cache does not cache the state of the actual entities in the result set;
it caches only identifier values for an individual query.
So the query cache should always be used in conjunction with the second-level cache.
Query Cache validation
OPERATIONS
INSERT :
UPDATE :
DELETE :
USAGE :
TODO :