[#16031] - Just update the timestamps for core sample data
- Closed
- 14 Aug 2017
- Medium
- Build: staging
- # 16031
- Diff
- zero-24:just_change_core_sampledata
- Success hound No violations found. Woof! Details
- Success continuous-integration/drone/pr the build was successful Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
User tests: Successful: Unsuccessful:
Pull Request for Issue #15961
Summary of Changes
This now limit the timestamp updates just to the core sample data.
Testing Instructions
- download: https://github.com/zero-24/joomla-cms/archive/just_change_core_sampledata.zip
- install as normal joomla with core sample data
- the dates should be updated
- add a sql update file (to be provided by @hendrikbehncke) to the following folder: https://github.com/zero-24/joomla-cms/tree/just_change_core_sampledata/installation/sql/mysql
- confirm the dates are not touched and the same as the values as provided.
Expected result
The core files are uptodate and the 3rd Party files are not.
Actual result
The core and 3rd party files are uptodate.
Documentation Changes Required
It should be noted somewhere that this is only happening now for the core.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Installation |
We should not be handling data sets differently based on whether it was something we created or something that someone added to the installer through a supported path. So either it should always be updated or never be updated. The argument in that issue is basically "I want what is in the SQL dump to be inserted to the database with minimal (if any) changes", which is fine, but it should also be consistent across the board.
which is fine, but it should also be consistent across the board.
any suggestions on how to handle that than?
Either we close the other issue as expected behavior or we change the installer to not change the timestamps. Either way it should be consistent, this introduces inconsistency.
Either we close the other issue as expected behavior or we change the installer to not change the timestamps.
What do you think about some kind of flag system? But i guess this is just to overcomplicated
I guess it would be possible as well since the respective plugin would be responsible for inserting the data. If it's done by a direct query or using models wouldn't matter.
This PR is what was in my mind. I see the point with inconsistency, but from my point of view there is already (some kind of) inconsistency in excluding 'sample_testing.sql'.
Maybe not updating the timestamps during installation at all but updating the sql files is the correct way then? As brianteeman said, we need to keep the dates provided in the sql file.
@zero-24 installed just_change_core_sampledata.zip, dates are updated. Where to find "… sql update file (to be provided by @hendrikbehncke) …"?
Why not simply update the dates in our sql to 2017 and then remove the code that did the magic to change the sql on install to today
| Status | Pending | ⇒ | Information Required |
| Status | Information Required | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-08-14 05:34:26 |
| Closed_By | ⇒ | zero-24 |
To be more accurate it should be noted that it only happens for sample data with those filenames.