-
-
Notifications
You must be signed in to change notification settings - Fork 365
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
Updates Expires attribute on Model Updates #420
Conversation
Pull Request Test Coverage Report for Build 663
💛 - Coveralls |
@devotox Thanks for this! I think we do want to add documentation for this PR as well as write some tests for this. I think we also need to confirm if this is a breaking change or not. We want to keep the existing behavior for the defaults as is I believe for this, and allow the user to pass in an option or something to overwrite the behavior. |
Documentation updated & default is false so should not be a breaking change |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking really good. Let's add some tests as well. I think we should add test(s) for both ensuring that the default behavior remains false, and behaves accordingly. As well as test(s) for ensuring that enabling that option and setting it to true behaves as expected. Any other ideas for tests are most welcome as well.
lib/Model.js
Outdated
@@ -539,6 +539,11 @@ Model.update = function(NewModel, key, update, options, next) { | |||
options.updateTimestamps = true; | |||
} | |||
|
|||
// default updateExpires to true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be false
, correct? In this comment? Although it's just a comment, probably a good idea to ensure it is correct.
@devotox Great work on this!! I think this will be a very welcome feature. Just left a review with a few comments. Have you confirmed that this feature is not already built into Dynamoose? I'm pretty confident it has not been built into Dynamoose yet, but I just want to verify. |
@devotox This will be a very welcome feature and I know personally I will use it very extensively. So thank you for this!! |
@fishcharlie yes this has not been built into Dynamoose yet. Looking to get some time to write the tests. tried to quickly throw some together based on updateTimestamps but alas it failed lol. So gotta sit down and see why but comment updated at least |
@fishcharlie Ive added tests but i noticed you are not testing updateTimestamps options in the schema tests. Shouldn't that be done and then also updateExpires. At the moment you only test this on Model.save |
I take that back you can't update timestamps from the schema 😝. Are we sure we do not want updateExpires: true as default. it seems like it is something that should be. |
@devotox If you have a strong argument for changing the default/current behavior feel free to make that argument. I'm all for changing default behaviors if it is justified. It also has to take into account the fact that upgrading Dynamoose then will cause problems for people who are relying on the current behaviors. If we draw the conclusion that we should change the current behavior this will need to be part of v1.0 probably. I will try to hold off on pushing v1.0 until we determine that, but I'm in the very final stages of that deployment, and a lot of my projects are gonna rely on v1.0, so we do kinda need to figure this out. If that doesn't make it into v1.0 we can always bring it up again for v2.0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. Let's add a few more tests. I think we should have a test to ensure the default is correct if we don't pass options into the .save
function. And does this support the Model.update
function. If so let's add tests for that. If not, it should probably be supported there as well.
lib/Model.js
Outdated
@@ -298,11 +298,19 @@ Model.prototype.put = function(options, next) { | |||
options.overwrite = true; | |||
} | |||
|
|||
let toDynamoOptions = {updateTimestamps: true}; | |||
let toDynamoOptions = { | |||
updateExpires: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need this, correct? It should just default to false by default without having this line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand your point but isn't it better to have the default set so it is visible through the system that it is actually set to something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@devotox I'm pretty sure the only reason to have it there is to increase readability and ease of understanding for developers in the future. Anytime we are comparing that value to false
or true
, undefined
will behave just like false
. So I don't think removing this is a bad thing. Especially since it looks like you did and all the tests are passing. If you believe there is an edge case that your tests haven't accounted for that this would break please write a test and if that test fails then yes we should totally add it back in.
lib/Model.js
Outdated
@@ -539,6 +547,11 @@ Model.update = function(NewModel, key, update, options, next) { | |||
options.updateTimestamps = true; | |||
} | |||
|
|||
// default updateExpires to false | |||
if (typeof options.updateExpires === 'undefined') { | |||
options.updateExpires = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once again I don't think we need this section. 'undefined' is considered falsey so I don't think we need this part since the default will be undefined or false.
test/Model.js
Outdated
|
||
it('Save existing item without updating expires', function (done) { | ||
var myCat = new Cats.Cat10({ | ||
id: 1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's make sure this id
is unique to ensure we aren't getting conflicts with the test above.
test/Model.js
Outdated
myCat.save({updateExpires: false}, function () { | ||
Cats.Cat10.get(1, function(err, realCat) { | ||
realCat.name.should.eql("FluffyB"); | ||
realCat.expires.should.eql(expectedExpires); // expires should be different than before |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the comment read expires should be the same as before
? Or something along those lines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@devotox This looks really good. Do you think we are ready to get this merged in or is there still more work to do? |
@fishcharlie I just need to write the update tests. Yesterday when I tried couldn't get access to the updated expires attribute to compare them but will make another attempt this morning. |
@devotox Let me know if I can help at all! |
@devotox Looks like there are some merge conflicts as well. This is the last PR I'd like to get in before version 1.0. But if we can't get it done before version 1.0 we can hold off till version 1.1. I'm aiming on getting version 1.0 out hopefully this week or this weekend. |
Haaa looks like the merge broke something .... gonna look into this |
@devotox Sounds good! And you still have one more test to write, correct? |
@fishcharlie Test added. Probably too late for the Release but here it is |
Also if this is a full version release we could technically make updateExpires default to true? |
@devotox Awesome. So is this ready to be merged in? Why do you believe defaulting to true is the better option here? |
@fishcharlie Yes, i believe it can be merged. And I keep trying to think of a good argument or find something as proof but maybe I'm wrong. It just feels like that makes sense. "A document is expired a certain period from its last update" |
@devotox This looks great. I’ll merge today. I’m on my phone so I can’t merge this in right now, but I’ll do it today for sure. Dynamoose v1.0 will be released today, and we will get this in for that version. Due to the fact that I don’t see a super compelling argument for setting the default to true I’m going to leave the default set to false. I’m totally willing to reconsider for another major version. But I’m normally against packages doing too much magic behind the scenes. By default I believe Dynamoose shouldn’t heavily change the behavior of DynamoDB, especially in regards to this. It’s easy for developers to toggle this switch. For new people to Dynamoose having the default be true might lead to a lot of confusion, which I think it would be good to prevent. Especially coming from the native AWS SDK. Thanks for all your hard work on this!! I really appreciate it! |
@fishcharlie You make a lot of sense with that. It should stay as close to the AWS SDK in that sense! |
Summary:
Allows the Expires attribute to be updated everytime the model updates.
This makes sense because you would want something to expire after it has not been touched for a certain amount of time not just from the time it was created
Type (select 1):
Is this a breaking change? (select 1):
Is this ready to be merged into Dynamoose? (select 1):
Are all the tests currently passing on this PR? (select 1):
Other:
npm test
from the root of the project directory to ensure all tests continue to pass