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

Fix timestamp() setting a key named "null" in some cases #1820

Merged
merged 2 commits into from Apr 24, 2018
Merged

Conversation

@ricardograca
Copy link
Member

@ricardograca ricardograca commented Apr 23, 2018

Introduction

The previous PR introduced a bug where a model could end up with a key named "null" if the user specified a custom hasTimestamps value that included a literal null as the second key name. This would lead to a SQL error complaining about a nonexistent column named "null" or "undefined".

Proposed solution

This checks if a updatedAt key exists first before attempting any other comparisons. The problem was in the first condition that would incorrectly return true if the key hadn't been set, even though it should only be checking if it had been set by the user.

- This would only happen if the user had set a custom value for
hasTimestamps that included a literal null value for the updated_at key.
@ricardograca ricardograca added this to To Do in Version 0.14.0 via automation Apr 23, 2018
@ricardograca ricardograca changed the title Rg null key Fix timestamp() setting a key named "null" in some cases Apr 23, 2018
@ricardograca ricardograca moved this from To Do to In progress in Version 0.14.0 Apr 23, 2018
@ricardograca ricardograca merged commit c3812ad into master Apr 24, 2018
1 of 2 checks passed
1 of 2 checks passed
continuous-integration/travis-ci/push The Travis CI build failed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Version 0.14.0 automation moved this from In progress to Done Apr 24, 2018
@ricardograca ricardograca deleted the rg-null-key branch Apr 24, 2018
@amaranadh-wal
Copy link

@amaranadh-wal amaranadh-wal commented Jun 14, 2018

If we give only created_at attribute in the array it is taking undefined in the insert query instead of updated_at.

For example

export default homeBookshelf.Model.extend({
  tableName: 'notifications',
  hasTimestamps: ['created_at'], ...

For above model declaration the query is going like

insert into 'notifications' ('created_at', 'initiator_id', 'initiator_type', 'notification_group_id', 'undefined', 'user_id') values ('2018-06-14 15:41:18.019', 333, 'user', 187, '2018-06-14 15:41:18.019', DEFAULT)

If we give like

export default homeBookshelf.Model.extend({
  tableName: 'notifications',
  hasTimestamps: ['created_at',null],

Then the query is going like

insert into notifications ('created_at', 'initiator_id', 'initiator_type', 'notification_group_id', 'null', 'user_id') values ('2018-06-14 15:40:41.754', 322, 'user', 180, '2018-06-14 15:40:41.754', DEFAULT)

So, I have given false value for the > hasTimestamps then it is working.

@ricardograca
Copy link
Member Author

@ricardograca ricardograca commented Jun 14, 2018

Have you tried the code that is in this change or are you referring only to the published version 0.13.3?

@amaranadh-wal
Copy link

@amaranadh-wal amaranadh-wal commented Jun 14, 2018

@ricardograca
Copy link
Member Author

@ricardograca ricardograca commented Jun 14, 2018

This PR you're commenting on fixes that then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants