Skip to content
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

Remove String manipulations of Date objects #271

Merged
merged 3 commits into from
May 2, 2017

Conversation

bbito
Copy link
Contributor

@bbito bbito commented Apr 25, 2017

Description

This is replacing PR #268 after rebase went badly.

Pull Request requested by @kjdelisle regarding #149 following my proposed solution "A" at #149 (comment).
As mentioned in the post linked above, this change allows the underlying mysqljs/mysql module to handle Date object serialization and removes the forced conversion of Dates to UTC Strings. An opt-out fallback to forced coercion to UTC is included, which was modeled after #265 from @darknos .

Previously timezone values specified in datasources.json had no effect on the underlying mysqljs/mysql module because Loopback was converting the Dates to Strings before handing off to the driver module.
With this change, timezone values specified in datasources.json provide the expected behavior only if "legacyUtcDateProcessing" is explicitly set to false in datasources.json, e.g.
"legacyUtcDateProcessing": false

This PR was made under conditions spelled out in the related issue thread #149 that I have limited time and expertise as a contributor and do not plan to personally address the test creation and documentation outlined in the action plan from @bajtos as pertains to this correction of long-standing undocumented forced coercion of Date types to UTC.

Please label: breaking-change, bug as per #149

Related issues

Checklist

  • New tests added or existing tests modified to cover all changes
  • Code conforms with the style
    guide

@slnode
Copy link

slnode commented Apr 25, 2017

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

@slnode
Copy link

slnode commented Apr 25, 2017

Can one of the admins verify this patch?

2 similar comments
@slnode
Copy link

slnode commented Apr 25, 2017

Can one of the admins verify this patch?

@slnode
Copy link

slnode commented Apr 25, 2017

Can one of the admins verify this patch?

@kjdelisle
Copy link
Contributor

@slnode test please

@kjdelisle
Copy link
Contributor

@slnode test please

@ssh24
Copy link
Contributor

ssh24 commented Apr 27, 2017

@bbito Could we add some test cases?

@kjdelisle
Copy link
Contributor

@ssh24 As previously discussed, we'll be making the tests for this instead.

@kjdelisle
Copy link
Contributor

kjdelisle commented Apr 27, 2017

@bbito Would I be able to begin working on this PR? I want to make sure everything's sorted out before I begin modifying this branch (adding tests)

@kjdelisle kjdelisle added the bug label Apr 27, 2017
@bbito
Copy link
Contributor Author

bbito commented Apr 27, 2017

@kjdelisle Hell's yeah! Let me know if you need anything from my end, I'm mostly on email, but sometimes doing client care for ~1 hour at a time and not checking.

@darknos
Copy link
Contributor

darknos commented Apr 27, 2017

@kjdelisle @bbito You can use test cases from #257 as starting point.

@bbito
Copy link
Contributor Author

bbito commented Apr 27, 2017

@darknos Thanks! I owe it to you that movement is finally happening on this bug that's been wasting my time since last year - Thank You!

This commit contains all previous work after rebase went badly
RE: Pull Request requested by @kjdelisle regarding loopbackio#149 following my
proposed solution "A" at loopbackio#149 (comment).
As mentioned in the post linked above, this change allows the
underlying mysqljs/mysql module to handle Date object serialization
and removes the forced conversion of Dates to UTC Strings.
An opt-out fallback to forced coercion to UTC is included,
which was modeled after loopbackio#265 from @darknos .

Old, squashed commits:
d0ea1d9
Legacy UTC date processing fallback credit: @darknos

a59dad7
Remove orphaned string functions

e8fdbdc
Incorporate @darknos expanded check for zero dates

abd4e0a
Remove DATE manipulations in from/toColumnValue
To sync with loopback-datasource-juggler #1356
which introduces new Type: DateString
@kjdelisle
Copy link
Contributor

@slnode test please

@@ -0,0 +1,93 @@
// Copyright IBM Corp. 2013,2016. All Rights Reserved.
// Node module: loopback-datasource-juggler
Copy link
Contributor

Choose a reason for hiding this comment

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

Wrong module name. And copyright year.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, yuck. Fixing

createdAt: new Date(),
}).then(function(inst) {
inst.should.not.eql(null);
inst.dob.toString().should.eql(d.toString());
Copy link
Contributor

Choose a reason for hiding this comment

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

I might be wrong, not sure does create return the same data in cb as find returns. According to the next test, you want to test the data returned by find :)

Copy link
Contributor

@kjdelisle kjdelisle May 2, 2017

Choose a reason for hiding this comment

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

Fixing.

Copy link
Contributor

@ssh24 ssh24 left a comment

Choose a reason for hiding this comment

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

LGTM

var fmt = require('util').format;
var should = require('./init.js');

var db, Order, Person;
Copy link
Contributor

Choose a reason for hiding this comment

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

Order ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah Order doesn't seem like its being used.

name: String,
gender: String,
married: Boolean,
dob: DateString,
Copy link
Contributor

Choose a reason for hiding this comment

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

I think after DateString get registered to a model, user don't have to specify this type by requiring the file in datasource directly, you can define it by doc: {type: 'datestring'} then model builder knows its type right?

Copy link
Contributor

@jannyHou jannyHou left a comment

Choose a reason for hiding this comment

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

three minor comments, LGTM

@kjdelisle
Copy link
Contributor

@slnode test please

@kjdelisle kjdelisle merged commit 3fa5306 into loopbackio:master May 2, 2017
@kjdelisle
Copy link
Contributor

@bbito Merged. :)

@bbito
Copy link
Contributor Author

bbito commented May 2, 2017

@kjdelisle Hey Great News! Thanks for taking that on!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants