A smart way to “force” some entity to be flagged as “updated” without overriding propel entity?

UPWG9AYH2

Hello,

is there a smart way to “force” some entity to be flagged as “updated” without overriding the propel entity behaviour at all? For example if we write price data into the storage table, the lastUpdate date is updated in this moment … but if we fetch later the exact price data again, the record is not marked as some updated record since the data is the same, but we actually compare this date to decide when to refresh prices …. so the first idea is to “touch” the record manually even if the record didn’t changed at all … any possibilities?

Best

U01A5ARAXP0

You can disable the propel events during that operation, like it is done with the imports

U01A5ARAXP0

Or if it is a different problem, you could just add a new column like last_checked_at

UPWG9AYH2

Does disabling the events leads to touching the record?
The last checked at column was also an idea, but we don’t see any necessity since there is always an “updated” and “created” column added by the timestampable behaviour

U01A5ARAXP0

the updated_at column is updated whenever the record is saved. If I'm not mistaken, even if the data didn't change.
Just by fetching data, that value will never change

UPWG9AYH2

Hmmm what i noticed is, that the “modified” property of the entity gets involved here … and what i observed is, that when you set fields exactly as before (for example “netAmount”) than the “modified” is left as “false” which will not lead to any touch in the db … maybe i miss something

U01A5ARAXP0

yes, true, this is an example of the code that does that:

U01A5ARAXP0

U01A5ARAXP0

what is exactly the flow you are trying to achieve?

UPWG9AYH2

we implemented some price fetching mechanism that fetches prices for a merchant/customer relation whenever a certain time exceeded … for yves we use the redis client to look at the “updatedAt” column for the corresponding record in the price storage (to dont make any call to zed backend and keep performance) … but for zed backend operations we have a look at the corresponding “updatedAt” column in the price storage tables … this works so far since the storage table and the redis entry will have approximately the same timestamp (bit difference cause of sync times maybe, but it doent matter since the timeout range is usually fairly high in our use case)
So yes, it might be the cleaniest but also the most ellaborate solution to add an additional field which will be transported to all the layers from frontend to backend … this was the reason we decided to go for this solution

U01A5ARAXP0

ok, but still with the propel behavior, you can modify the updated_at column directly

UPWG9AYH2

but in the entity itself, right?

U01A5ARAXP0

yes, sure

U01A5ARAXP0

you can do

$entity->setUpdatedAt(new Datetime());
$entity->save();

UPWG9AYH2

okay i think i have an error explaing it correctly^^ … a “PriceProductstoreEntity” leads to its attached “eventbahviour” that the corresponding entity in the “spy_price_product_concrete_merchant_relationship_storage” table is not written since it was not touched (because no change happened) … so, i cannot write the updated_at column because i just can change the the priceproductstore table in the place … so anyhow, i have to tell the priceproductstore table that it is now touched and the event behaviour will write a new/updated entry into the corresponding dtorage table (we use for comparison)

UPWG9AYH2

$priceProductStoreEntity->getGrossPrice() //returns for example "100"
$priceProductStoreEntity->setGrossPrice(100)
$priceProductStoreEntity->save() //will not lead to a updated storage entry in spy_price_product_concrete_merchant_relationship_storage since the price didn't change in fact

UPWG9AYH2

One hackish solution might be to set the price to “null” before saving the new old one^^

UPWG9AYH2

But also implies performance loss cause of multiple facade calls

U01A5ARAXP0

I guess for that specific logic, the safest and best way is to have a dedicated column

UPWG9AYH2

I fear you are right 😄 i was so glad to NOT touch all the P&S related stuff ^^

UPWG9AYH2

Honestly, it does not seem to be an easy solution since the price publishing is not that easy to extend … there are some places where the data field for the storage does not base on a transfer based array but on a manually created structure which is deeply buried in the core logic … i think it might be easier to introduce another plain storage table where just the “synchronizedAt” and the corresponding “priceProductStoreId” is saved and published when synchronizing prices ….

UPWG9AYH2

I think this was the origin reason why i not really wanted to go this way

U01A5ARAXP0

so let me recap... what you want is when you save the entity, if there is no price change, you still want to update the storage updated_at, is that it?

UPWG9AYH2

yep

U01A5ARAXP0

what you need to do is to trigger the event that the storage writer is listening to, with the correspondent id

UPWG9AYH2

but then anyway .. when it comes to write the storage

“data” is in this case exactly the same as before and therefore no column marked as changed -> no write to db

UPWG9AYH2

The only way i see is to involve the “latsSyncDate” in the data field which will lead to a alternate data value and then gets marked as update … but as i said, writing to the data payload is not that easy as it sounds

U01A5ARAXP0

true... so either you change the storage entity updated_at directly and force the sync, or you trigger a new custom event and add custom code to handle that specific event in that way

UPWG9AYH2

yes, i fear i have no other chance … really sad about that, since the pricing stuff isn’t really the less complex one 😞
But thanks in any case for your help 🙂

U01A5ARAXP0

no prob, good luck 💪