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

Modify interface and implementation of BulkInsertWithAssigningIDs #53

Open
wants to merge 12 commits into
base: epic-assigning-ids
Choose a base branch
from

Conversation

t-tiger
Copy link
Owner

@t-tiger t-tiger commented Nov 7, 2021

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.

Comment on lines +44 to +45
mock.ExpectQuery(
"INSERT INTO `tables` \\(`ThisIsCamelCase`, `regular_column`\\)",
Copy link
Owner Author

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.

Copy link
Collaborator

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.

Copy link
Owner Author

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.

Copy link
Collaborator

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?

Copy link
Owner Author

@t-tiger t-tiger Nov 11, 2021

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.

@t-tiger t-tiger marked this pull request as draft November 7, 2021 11:26
@t-tiger t-tiger self-assigned this Nov 7, 2021
bulk_insert.go Outdated Show resolved Hide resolved
@t-tiger t-tiger force-pushed the fix-epic-assigning-ids branch from d82904f to 4a389f9 Compare November 7, 2021 11:59
@t-tiger t-tiger force-pushed the fix-epic-assigning-ids branch from 4a389f9 to 4484575 Compare November 7, 2021 12:02
@t-tiger t-tiger marked this pull request as ready for review November 7, 2021 12:06
@t-tiger t-tiger requested a review from bombsimon November 7, 2021 12:06
@t-tiger
Copy link
Owner Author

t-tiger commented Nov 7, 2021

FYI: @laushunyu I've created a follow-up of your PR. Please check if you have time🙇

Copy link

@laushunyu laushunyu left a 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")

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.

Copy link
Owner Author

@t-tiger t-tiger Nov 9, 2021

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?

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

Copy link
Owner Author

@t-tiger t-tiger Nov 16, 2021

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.

Choose a reason for hiding this comment

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

good idea

bulk_insert.go Outdated Show resolved Hide resolved
var returned []struct {
ID int
Name string
CreatedAt time.Time
}

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")

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}, ...}
Copy link

@laushunyu laushunyu Nov 8, 2021

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

Copy link
Collaborator

@bombsimon bombsimon left a 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.

bulk_insert.go Outdated Show resolved Hide resolved
Comment on lines +44 to +45
mock.ExpectQuery(
"INSERT INTO `tables` \\(`ThisIsCamelCase`, `regular_column`\\)",
Copy link
Collaborator

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.

bulk_insert.go Show resolved Hide resolved
@@ -26,6 +26,78 @@ type fakeTable struct {
UpdatedAt time.Time
}

func TestBulkInsertWithReturningValues(t *testing.T) {
Copy link
Collaborator

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.

Copy link
Owner Author

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.

Copy link
Collaborator

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.

@t-tiger t-tiger requested a review from bombsimon November 15, 2021 00:34
Copy link
Collaborator

@bombsimon bombsimon left a comment

Choose a reason for hiding this comment

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

LGTM!

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

Successfully merging this pull request may close these issues.

3 participants