-
Notifications
You must be signed in to change notification settings - Fork 63
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
Modify interface and implementation of BulkInsertWithAssigningIDs #53
base: epic-assigning-ids
Are you sure you want to change the base?
Conversation
mock.ExpectQuery( | ||
"INSERT INTO `tables` \\(`ThisIsCamelCase`, `regular_column`\\)", |
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'd like to test with actual DBs using Docker containers as a follow-up task.
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.
Personally I don't think that's necessary since this supports multiple dialects so it would require multiple containers. Also the only goal for this project is to generate SQL, not handle or parse the dialect nor handle connections.
An example directory with a docker-compose file starting the DBMs to use as integration test might make sense but I don't think the unit tests should rely on that.
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 have been testing manually to see if it works in various cases like ID is int or string, and composite PK, and so on. But when I make a change like this, I feel it's inconvenient without automated tests.
An example directory with a docker-compose file starting the DBMs to use as integration test might make sense but I don't think the unit tests should rely on that.
Can I ask why we should not use DBMs for unit tests? With docker-compose, we can easily test with DBs, and since there are only two public methods, I don't feel integration tests are necessary.
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'm just used to unit tests being small and quick, testing the implementation but not the dependencies. But it's easy enough to use Docker for unit tests as well so if you feel it makes sense go for it!
Are you planning on testing all DBMs that Gorm support or only a subset?
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.
Are you planning on testing all DBMs that Gorm support or only a subset?
I'm planning to test with MySQL and PostgreSQL since most of the users likely to use, I guess.
d82904f
to
4a389f9
Compare
4a389f9
to
4484575
Compare
FYI: @laushunyu I've created a follow-up of your PR. Please check if you have time🙇 |
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.
Coooool PR!
It would be best if we suuport scanning []uint.
func BulkInsertWithReturningValues(db *gorm.DB, objects []interface{}, returnedVals interface{}, chunkSize int, excludeColumns ...string) error { | ||
typ := reflect.TypeOf(returnedVals) | ||
if typ.Kind() != reflect.Ptr || typ.Elem().Kind() != reflect.Slice || typ.Elem().Elem().Kind() != reflect.Struct { | ||
return errors.New("returnedVals must be a pointer to a slice of struct") |
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 can also accept *[]uint i think, it will be more useful.
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'm not a fan of accepting a different type in a single method, rather I'd like to have a dedicated method if we accept a slice.
The reason why I changed not to accept slice is, returning
statement is not only for PK, we can get values with multiple fields. Therefore, I thought we should support a wide range of use cases. However, I guess one of the major use cases is returning id that you proposed in the previous PR, so I can re-consider having a dedicated method like this.
func BulkInsertWithReturningIDs(db *gorm.DB, objects []interface{}, ids interface{}, chunkSize int, excludeColumns ...string) error
// Or we should rename to use "PK" instead of "ID"? But PK is not always a single column🤔
func BulkInsertWithReturningPKs(db *gorm.DB, objects []interface{}, pks interface{}, chunkSize int, excludeColumns ...string) error
What do you think?
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.
how about
func BulkInsertPluckingReturning(db *gorm.DB, objects []interface{}, column string, columnData interface{}, chunkSize int, excludeColumns ...string) error
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.
Hmm, I feel BulkInsertWithReturningIDs
seems better. If the caller wants to get values except for id
column, it's still able to use BulkInsertWithReturningValues
. If you agree to this, I'll implement as soon as possible and merge it.
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.
good idea
var returned []struct { | ||
ID int | ||
Name string | ||
CreatedAt time.Time | ||
} |
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 i only need ID
, i would define
var returned []struct{
ID uint
}
scan it from result then
var ids []uint
for _,ret := range returned{
ids = append(ids, ret.ID)
}
it's odd...
its nessessary to support *[]uint or *[]string, i suggest.
bulk_insert.go
Outdated
// | ||
// [returnedValue] slice of primary_key or model, must be a *[]uint(for integer), *[]string(for uuid), *[]struct(for `returning *`) | ||
// [db] must be set with "gorm:insert_option" to execute RETURNING clause. e.g. db.Set("gorm:insert_option", "RETURNING id") |
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.
how about check using db.Get("gorm:insert_option")
then warn it to avoid the confusing empty reply?
README.md
Outdated
fmt.Printf("success to insert with returning: %+v\n", returnId) | ||
// `success to insert with returning: [4 5 6]` | ||
// Values of `returned` will be like this | ||
// {{ID: 1, Name: "name0", CreatedAt: 2021-10-31 16:21:48.019947 +0000 UTC}, ...} |
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.
{ID: 11,...},{ID: 12,...},...
there are 10 records existed before, haha
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.
Nice followup! I have no strong feelings around this but a suggestion on how to make this easier to the caller by setting the insert optipn based on the passed struct now that we require one.
mock.ExpectQuery( | ||
"INSERT INTO `tables` \\(`ThisIsCamelCase`, `regular_column`\\)", |
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.
Personally I don't think that's necessary since this supports multiple dialects so it would require multiple containers. Also the only goal for this project is to generate SQL, not handle or parse the dialect nor handle connections.
An example directory with a docker-compose file starting the DBMs to use as integration test might make sense but I don't think the unit tests should rely on that.
@@ -26,6 +26,78 @@ type fakeTable struct { | |||
UpdatedAt time.Time | |||
} | |||
|
|||
func TestBulkInsertWithReturningValues(t *testing.T) { |
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.
Still think this test case should be simplified without column options and fields not needed.
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.
You mean, we don't need insert_option
related to #53 (comment) ? Sorry, I could not understand very well.
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.
It's a super nit but I just mean the test is copied when testing custom field tags so this test is also using the field tag gorm:"column:ThisIsCamelCase"
. I think that's confusing since we already test that feature in a different test, this test could use a simpler struct.
type Table struct {
ID uint `gorm:"primary_key;auto_increment"`
ColumnOne string
ColumnTwo string
}
And then just refer to the default column names column_one
and column_two
.
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!
This PR is a follow-up of #50.
Method only accepts a slice of struct for returning values
Previous PR accepts both slice of PK and slice of struct, but I feel it should be consistent and natural to just accept a slice of struct. Although the initial motivation was returning the created IDs, DB can return the multiple specified columns, so I think it would be better not to stick to returning PK as a library.
Modify README
Change the example using
BulkInsertWithReturningValues
.