-
Notifications
You must be signed in to change notification settings - Fork 181
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
default values added for new required columns when running autoupdate() #418
Conversation
Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test." |
@agnes512 npm test fails on jugglerv3/v4, if i just test this particular module, it passes everything. juggler v3/v4 tests are failing even without making any changes |
when running autoupdate(), default values are added for new columns Signed-off-by: Karan Raina <[email protected]>
@karanssj4 yes v3/v4 sometimes fail randomly :( but don't worry about it in this PR. And thanks for the PR ! I will review it shortly. |
@slnode test please |
@karanssj4 I checked those failures. Actually they are causing by the changes. The tests in this repository are run, so are the tests in Juggler to check the persistence.
it's expecting I am not sure if it was an intentional decision. But I think |
@karanssj4 Thank you for the patch! I think the juggler test expects the following behavior: When a new column with default value gets added to a database, the existing data will have a null value(null or undefined, depends on the db) instead of the default value for that new column. So is there a way to follow ^ behaviour when create new columns in postgresql? |
@jannyHou should default values be only added when you add a new required column? Or should they be added for non required columns as well? I prefer the second one, because If I'm explicitly telling a new column should be added with a default value, then it should have that default value. If I wanted to make new values null, I'd have not added a default value I just confirmed this is the behavior of pstgresql as well.
This results in a new column b6 and all values are 11 for the existing rows |
I checked out loopbackio/loopback-datasource-juggler#1704 and The test case was written so as to NOT return a default value if the database doesn't have it. Here, the database in question does have the default value (that's how Postgres handles it) @bajtos @jannyHou any thoughts on how should this be handled? |
I think I was involved in past discussions about handling default values, I'll try to find them to refresh my memory and then review the proposal and discussion here. I am not sure if I'll find enough time this week, I'll aim to get it done by Tuesday 2020-02-25. (Feel free to ping me if I don't.) |
@@ -230,3 +260,4 @@ function checkColumns(table, cb) { | |||
cb(err, cols); | |||
}); | |||
} | |||
|
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.
Extra EOL at EOF, please remove.
I reviewed the proposed code changes, they look reasonable to me 👍 Regarding the failing test from juggler: this is tricky! As have been correctly wrote above, the test was written with the assumption that when a new optional column with a default value is added to an existing table, existing records will have
I think the scenario described above is still valid, we just need to find a way how to improve the test to work with connectors that are setting the newly added column to the default value for existing rows as part of For example, we can rework the test to define the new property in two steps:
Alternatively, we can look for better ways how to test the scenario we were fixing as part of the pull request which introduced the problematic test. Quoting from loopbackio/loopback-datasource-juggler#1692 (comment) again:
As yet another alternative, we can modify the connector to configure SQL columns with the provided default value only when the property is also I remember that LoopBack treats |
@bajtos here's my $0.02 on this. If someone wants a new column with null values, they wouldn't register a default value (at least in SQL). If the user doesn't wanna do that..then worst case scenario, they would make a new column without default values, run autoupdate, then add a default value, run autoupdate again |
Similar issue loopbackio/loopback-connector-mongodb#564 (?) |
@bajtos @jannyHou any pointers on how to proceed finally? should I keep it as is and update juggler tests? should I keep it only for required default values?
do you agree with this? |
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.
If someone wants a new column with null values, they wouldn't register a default value (at least in SQL).
I haven't tested with other SQL dbs, but given the native query you post in
ALTER TABLE "tag"
ADD "b6" smallint NULL DEFAULT '11';
I tend to honor postgresql's behavior. The juggler tests passed before because the default column was not built, at least in this connector, so I would go with the fix here and update the juggler test.
Maybe update it to honor a connector's behavior? E.g. postgresql sets default value when new column added while some connector don't (!! might be a wrong assumption, maybe all behave like postgresql).
But I don't know if ^ would violate the fix in PR loopbackio/loopback-datasource-juggler#1704 :p Will respect @bajtos 's opinion on this.
await DefaultValueAfterColumnAdd.create({ | ||
name: 'name1', | ||
}); | ||
await db.defineProperty('DefaultValueAfterColumnAdd', 'createdByAdmin', { |
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.
defineProperty
is a sync function I think, see its definition
I can update Juggler's tests if needed :D |
I am afraid I won't be able to review these changes in the next 2 weeks. @hacksparrow IIRC, you were involved in recent changes related to handling of default values, can you please take a look at this pull request? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the |
can we open this again? @bajtos |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the |
1 similar comment
This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the |
Need to open this again. This is still an issue in 2024. |
Fixes #123
Checklist
👉 Read and sign the CLA (Contributor License Agreement) 👈
npm test
passes on your machine