Skip to content
This repository has been archived by the owner on Jun 29, 2021. It is now read-only.

Resolves #28, #29: "Update timestamps columns on links and tags tables" #38

Merged
merged 10 commits into from
Oct 16, 2020

Conversation

ialexreis
Copy link
Contributor

  • drop regular timestamps columns
  • create new ones with timestampsTz

@ialexreis
Copy link
Contributor Author

@josepostiga Here is my draft PR, I will continue to work on that!

#28
#29

@josepostiga josepostiga changed the title feat(Tags): add support to timestamps w/timezones Resolves #28 and #29: "Update timestamps columns on links and tags tables" Oct 8, 2020
@josepostiga josepostiga changed the title Resolves #28 and #29: "Update timestamps columns on links and tags tables" Resolves #28, #29: "Update timestamps columns on links and tags tables" Oct 8, 2020
- drop regular timestamps columns
- create new ones with timestampsTz
@ialexreis
Copy link
Contributor Author

@josepostiga I have a doubt... When you say: "Besides that, ensure that the application layer sets the database timezone based on the incoming request.", what do you expect me to do?

Maybe send this information inside the db query, like including the timestamps field inside the query?

@josepostiga
Copy link
Member

@ADeVR when dealing with timezones, the best, less error-prone, strategy, is to ensure that all date/time properties are always stored and get as UTC, calculating the difference from whatever timezone the client sends, and expose that date always as UTC and let the clients being responsible to show it and calculate any time difference as appropriate.

However, there are other valid strategies:

  1. Passing the date/time calculations to UTC to the database layer, with specific queries to change the timezone used for a specific request; or
  2. Completely rely on the information received from the clients, storing and showing it as-is, agreeing that they'll always send the full ISO 8601.

I admit the wording, there, wasn't the best and I'll rectify it. But the option I'd like to see implemented is the "save and show always as UTC", as described in the first paragraph of this response.

@ialexreis
Copy link
Contributor Author

@josepostiga oh ok, no problem at all!

Thinking about a good solution, maybe I should implement a custom cast type for that, and use it in every date, to force that specific behaviour.

But in that case, in order to not break the domain driven structure, where do you think that the cast should be located?

@josepostiga
Copy link
Member

josepostiga commented Oct 11, 2020

@ADeVR that's the default framework's behavior. It'll save any date/time declared property to UTC and get that same property back with the calculated difference to the configured framework timezone (that by default is UTC, too).

We just need to ensure that other date/time properties besides the framework "default" ones (created_at, updated_at, deleted_at) are declared as datetime in the $casts property of the model class.

@ialexreis ialexreis marked this pull request as ready for review October 11, 2020 15:46
@ialexreis
Copy link
Contributor Author

@josepostiga thanks for the help! I learned a lot with this PR! Anything you want me to improve feel free to comment about it!

I'm looking forward to help!

Copy link
Member

@josepostiga josepostiga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for submitting this PR @ADeVR. There's just a simple detail we need to work out but, after that, I believe we'll be ready to merge this! 👍

public function up(): void
{
Schema::table('links', function (Blueprint $table) {
$table->dropColumn(["created_at", "updated_at", "approved_at", "deleted_at"]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a continuous integration mindset, we never drop columns that might be in use, because that leads to loose of data. That's a valid strategy for unreleased software, which is not the case of this API.

Notice we already have some releases, and although we might assume that doing this is very unlikely to break anyone's code, we need to always think about what if someone already has data inserted that they don't want to lose?

I suggest we change this to use the change() method and let the database engine execute the proper SQL to update the already existent columns to the new type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@josepostiga sorry for the delay answering this. Since the documentation, states that the "Only the following column types can be changed", I've decided to not use the timestampsTz method and instead used the datetimeTz method, which allows me to change the types of the column!

Hope to contribute more! 😄

Copy link
Member

@josepostiga josepostiga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, let's get this merged! 🥳

Can you just update the CHANGELOG.md file and reference the related issue in the correct section?

@ialexreis
Copy link
Contributor Author

Well, let's get this merged! 🥳

Can you just update the CHANGELOG.md file and reference the related issue in the correct section?

Sure! I can do that now!

timestamps columns (on links and tags) changed to datetime w/timezone
@ialexreis
Copy link
Contributor Author

Changelog updated! 💯

@josepostiga josepostiga merged commit 1c3979d into laravel-portugal:master Oct 16, 2020
tiagof pushed a commit to tiagof/api that referenced this pull request Oct 17, 2020
… columns on links and tags tables" (laravel-portugal#38)

* feat(Tags): add support to timestamps w/timezones

- drop regular timestamps columns
- create new ones with timestampsTz

* feat(Links): add support to timestamps w/timezones

added doctrine/dbal dependency

* fix: add method return type

* fix(Links): add missing timestamp (approved_at)

* chore: converted timestampTz to softDeletesTz

* feat(links): added approved_at datetime cast

* fix: replaced dropColumn with change method

* chore(Changelog): add latest updates

timestamps columns (on links and tags) changed to datetime w/timezone
josepostiga pushed a commit that referenced this pull request Oct 25, 2020
* init

* Adds Question create feature

resolves #25
Removes unnecessary code in AccountsStoreController.

* Added '/discussions' prefix

As per #25 (comment)

* Minor fixes as per review

#40 (review)

* Cleanup

* Added question update

* Added tests

* Resolves #28, #29: "Update timestamps columns on links and tags tables" (#38)

* feat(Tags): add support to timestamps w/timezones

- drop regular timestamps columns
- create new ones with timestampsTz

* feat(Links): add support to timestamps w/timezones

added doctrine/dbal dependency

* fix: add method return type

* fix(Links): add missing timestamp (approved_at)

* chore: converted timestampTz to softDeletesTz

* feat(links): added approved_at datetime cast

* fix: replaced dropColumn with change method

* chore(Changelog): add latest updates

timestamps columns (on links and tags) changed to datetime w/timezone

* Resolves #25 - An authenticated user can post a question (#40)

* init

* Adds Question create feature

resolves #25
Removes unnecessary code in AccountsStoreController.

* Added '/discussions' prefix

As per #25 (comment)

* Minor fixes as per review

#40 (review)

* Cleanup

* Resolve conflicts + test tweaks

* Code cleanup + minor improvements

* minor tweaks

* final tweaks/cleanup

* style(Discussions): minor code style fixes

* ci(PHPUnit): add blade files to the code coverage exclusion list

Co-authored-by: Alexandre Reis <[email protected]>
Co-authored-by: José Postiga <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
2 participants