-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prefer DATETIME to DATE in the MySQL Database #45
Comments
Agreed 👍. @DedrickEnc @jniles do you think it's worthwhile budgeting ~half a day for Excellent suggestion backed with references. On Wednesday, January 27, 2016, Jonathan Niles notifications@github.com
|
We definitely need integration tests to support this proposition. I'm working on a few, updating @mbayopanda's employee API tests (which register a date of birth), as part of #24. That is probably not enough though. Another interesting experiment would be to see how large DATEs are compared to DATETIMEs. While I would still recommend using DATETIMEs over DATEs, it would be valuable information to have. |
This commit ensures that all integration tests pass during SQL strict mode. In particular, the following changes have been implemented: 1. Travis calls SET GLOBAL sql_mode = 'STRICT_ALL_TABLES' to ensure that it is running in SQL strict mode. 2. The following tables now use DATETIME instead of DATE (see #45) to store date entities: a. `patient` (dob, registration_date) b. `employee` (dob, date_embauche) c. `exchange_rate` (date) 3. A dependency on `chai-datetime` has been added to ensure dates are properly tested during integration tests. An example of this can be found in the Employees API tests. 4. Many controller refactors to pre-process dates or fix bugs revealed by failing tests. 5. Error handling has been moved into the `interceptors` file. Errors in the application are now functions, to be called as `new req.codes.ERROR()`. The syntax is liable to change in a future commit. 6. A series of database errors have been added to ensure that all errors are informative and handled uniformly. 7. Removed unused `errors.js` controller file. 8. Misc typos and style fixes.
This commit ensures that all integration tests pass during SQL strict mode. In particular, the following changes have been implemented: 1. Travis calls SET GLOBAL sql_mode = 'STRICT_ALL_TABLES' to ensure that it is running in SQL strict mode. 2. The following tables now use DATETIME instead of DATE (see #45) to store date entities: a. `patient` (dob, registration_date) b. `employee` (dob, date_embauche) c. `exchange_rate` (date) 3. A dependency on `chai-datetime` has been added to ensure dates are properly tested during integration tests. An example of this can be found in the Employees API tests. 4. Many controller refactors to pre-process dates or fix bugs revealed by failing tests. 5. Error handling has been moved into the `interceptors` file. Errors in the application are now functions, to be called as `new req.codes.ERROR()`. The syntax is liable to change in a future commit. 6. A series of database errors have been added to ensure that all errors are informative and handled uniformly. 7. Removed unused `errors.js` controller file. 8. Misc typos and style fixes.
Most, if not all, of our dates have been migrated. Closing this. |
* feature(locations): add register again checkbox This commit adds a "Register another Location" checkbox to the bottom of the location modal. This allows a user to register multiple locations with the modal before closing it. Closes #38.
As part of the bhima 2.X release cycle, I propose we migrate as many tables as possible to using DATETIME column types instead of DATE for storing date datapoints. Under this direction, we will design our table columns following these guidelines:
Date()
object. The SQL datatype does not convert records from their original timezone to UTC (like a TIMESTAMP does), preferring to store them in the time zone of the server.It is worth reading the page on MySQL dates [1]. Also useful is this [2] Stack Overflow discussion (see top two answers).
[1] http://dev.mysql.com/doc/refman/5.7/en/datetime.html.
[2] http://stackoverflow.com/questions/409286/should-i-use-field-datetime-or-timestamp.
The text was updated successfully, but these errors were encountered: