Reputation: 2331
I have a TYPO3 extension (extbase, TYPO3 7.6) and inside a controller showAction
, I increase the viewCounter
property of the given record and then call the $repo->update($entity)
on the corresponding repository class.
Problem is, that at another place of this website, there is a list of "changed" records which utilizes the tstamp
field of those records. So now the problem is, each time the entity is loaded, the counter is increased and the extbase internals also update the tstamp
value automatically. Which, in this case, is now wanted at all.
So my question is: Is it possible to deactivate or bypass this behavior for a certain query or maybe in general (activating it again afterwards)? Of course, I could completely bypass the extbase ORM and update that record with plain SQL myself, but I consider that a not so good solution :-)
Upvotes: 1
Views: 574
Reputation: 59927
Questions like this are best answered by looking at the code:
The tstamp
value is automatically updated by repo update
queries because of addCommonDateFieldsToRow
(called from updateObject
via addCommonFieldsToRow
). This automatism happens if $dataMap->getModificationDateColumnName() !== null
, which happens if the TCA $controlSection['tstamp']
of the respective table is set (which usually is the case).
As the $dataMap is cached, temporarily unsetting $GLOBALS['TCA']['your_table']['ctrl']['tstamp']
won't work. There don't seem to be any hook entry points before addCommonDateFieldsToRow
is being called, neither (there is emitAfterUpdateObjectSignal
, but this is called after the update - and there is no emit*Before*UpdateObjectSignal
).
A remedy could be implementing a UPDATEquery_preProcessAction hook and remove tstamp
from the $fields_values
for your query there. This hook will be called for every TYPO3 update query though.
Another workaround (one I often use) is to extend (XCLASS) the problematic core code. In your case, you could extend \TYPO3\CMS\Extbase\Persistence\Generic\Backend::addCommonDateFieldsToRow
and don't add the tstamp
column for your special domain object.
As I said in my comment to your question: instead of wasting time working around extbase conventions and limitations, the best solution often is to just bypass the extbase ORM with plain SQL.
PS: You might also consider changing your data model and moving the view counter to a separate table.
Upvotes: 1