Feature #55934: Entitycache for extbase - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Feature #55934

closed

Entitycache for extbase

Added by Philipp Wrann almost 11 years ago. Updated over 9 years ago.

Status:

Closed

Priority:

Could have

Assignee:

Category:

Extbase

Target version:

Start date:

2014-02-12

Due date:

% Done:

Estimated time:

PHP Version:

Tags:

Complexity:

hard

Sprint Focus:

Description

Lately i thought hard about a the implementation of a entity cache for my package but it would be a very nice-to-have generic feature i think.
By default turned of because for most projects everything is fine at the moment, but it should be possible to configure such a cache.

extbase_entitycache
An entry would look like
'\Vendor\Package\Domain\Model\Entity:1:0' = [
'uid' => 1,
'title' => 'Title',
'relations' => [
'Vendor\Package\Domain\Model\EntityB:1:0',
'Vendor\Package\Domain\Model\EntityB:2:0',
]
]

All non-transient properties would be saved this way (if simple type, storage or instanceof AbstractEntity)
Values would be Inserted without any validation
Cached entities would only be loaded for configured models and only in FE context.
So you would not have to care about corrupted cache entries causing wrong data in your database.

you could register slots on persistence signals of the extbase ORM
additionally you could implement a TCEMain Hook that creates/updates/deletes the cache entry on the fly
you could also register a task/hook to create the modelcache for all entities of that type (after clearing the cache or in a given time)

That way only real search-logic would be requested, but all results could again be mapped from the cache.
instancing lazy properties would event be much faster.

What do you think? Are there allready plans on that, is it realizeable?

I could try to realize it by myself but i am afraid, caused to my missing insight, it would never get production ready.

Actions

Copy link

Updated by Philipp Wrann almost 11 years ago

small update: transient properties of the same simple and Domain types could be saved to, so you could add transient properties like a rendered URL, a image thumbnail etc. to that cached entitiy and your application would even be faster. Especially image processing and link generation have bad performance and should make use of some kind of prefilled cache.

Actions

Copy link

Updated by Philipp Gampe over 10 years ago

You can use the caching framework to use an own cache in your controller. Should less than 20 lines of code.

Then you can save and retrieve the objects that you know that they don't change between requests.

Actions

Copy link

Updated by Viktor Livakivskyi over 10 years ago

Phillip, yes, own cache will be helpful, but this mean, that not only controller needs to be modified, but a set of BE hoooks added to clear relevant caches on new/update/delete/copy/move/localize/etc. operations.

It will increase boilerplate code for each extension, that would like to have caching of entites, while the goal of a framework is to reduce such code and save time of developer.

Actions

Copy link

Updated by Philipp Wrann over 10 years ago

In addition a database request, that does only return the primary key could be processed as index only scan (when the table has good indexes of course) and the the database would not need to load any of the table data. That could make the building even faster.

Just a few TCA settings are needed to realize that

1st: connect the table to the extbase model/superclass:
TCA[tx_extension_domain_model_test][extbase_model] = 'Vendor\\Extension\\Domain\\Model\\Test';

The general enabling:
config.tx_extbase.persistence.classes.Vendor\Extension\Domain\Model\Test.entityCache = 1

And to modify you could simply register a handler for the specific signal.
There you could add prebuilt imagepaths, links or other processed data.

When persisting an object the standard routine is called and postprocessed by the registered Handler.

When saving a TCA record via the backend the TCA is resolved, if an extbase entity class is connected and the cache is enabled the routine is called based on the TCA values.

I think it would not be so hard to implement, developerts could very easily enable it for their models and if you have good indexes and make good use of it you can have a very dramatic (positive) impact on performance.

Actions

Copy link