A smart way to “force” some entity to be flagged as “updated” without overriding propel entity?
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
Comments
-
You can disable the propel events during that operation, like it is done with the imports
0 -
Or if it is a different problem, you could just add a new column like last_checked_at
0 -
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 behaviour0 -
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 change0 -
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
0 -
yes, true, this is an example of the code that does that:
0 -
0
-
what is exactly the flow you are trying to achieve?
0 -
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 solution0 -
ok, but still with the propel behavior, you can modify the updated_at column directly
0 -
but in the entity itself, right?
0 -
yes, sure
0 -
you can do
$entity->setUpdatedAt(new Datetime()); $entity->save();
0 -
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)
0 -
$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
0 -
One hackish solution might be to set the price to “null” before saving the new old one^^
0 -
But also implies performance loss cause of multiple facade calls
0 -
I guess for that specific logic, the safest and best way is to have a dedicated column
0 -
I fear you are right 😄 i was so glad to NOT touch all the P&S related stuff ^^
0 -
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 ….
0 -
I think this was the origin reason why i not really wanted to go this way
0 -
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?
0 -
yep
0 -
what you need to do is to trigger the event that the storage writer is listening to, with the correspondent id
0 -
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
0 -
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
0 -
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
0 -
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 🙂0 -
no prob, good luck 💪
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 65 Spryker News
- 879 Developer Corner
- 743 Spryker Development
- 84 Spryker Dev Environment
- 360 Spryker Releases
- 3 Oryx frontend framework
- 33 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 22 Job Opportunities
- 3.2K 📜 Slack Archives
- 116 Academy
- 5 Business Users
- 370 Docker
- 551 Slack General
- 2K Help
- 75 Knowledge Sharing
- 6 Random Stuff
- 4 Code Testing
- 32 Product & Business Questions
- 68 Spryker Safari Questions
- 50 Random