Support binding max 512 columns/fields instead of 256#1038
Support binding max 512 columns/fields instead of 256#1038xc wants to merge 1 commit intoaarondl:masterfrom
Conversation
|
Unfortunately I think this is a backwards incompatible change. The way the pointer mappings work is that a single field is represented by a uint64 divided into 8 uint8. Each byte represents a level of recursion into a struct, ie: type User struct {
OneLevel struct {
TwoLevel struct {
} `boil:"two_level"`
} `boil:"one_level"`
}This PR does two things: Increases the column max columns, but unfortunately it also trades for max recursive depth as we're using 9 bits per column now meaning we can only fit 7 levels of depth. As is I don't think I can accept this. |
|
Thanks for the answer. Backward compatible wise it's true. For us and for most of users I think the more important is the field number instead of struct depth, but it's indeed about backward compatibility. Maybe it's better to use 2 dimension slice eg. [10][512]int for grouping(one for struct depth, one for that depth's fields) instead of uint64 which has max limit? then the 'mapping' variable will not be uint64, but [2]int(eg.{0,20}). Not sure if it will affect performance. I'm not sure I'm able to write a PR but I can have a try. |
|
It was definitely made this way for performance concerns so that's top of mind. |
|
Give me some time to think if there is other possible to increase column number. Will update this. |
256 in a struct(not including embed struct) is bit small for us. We have 260 fields for now and may add more.
Also max columns better to be documented(in readme?).
Thanks.
XC