-
Notifications
You must be signed in to change notification settings - Fork 20
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
Library split #747
Library split #747
Conversation
e044278
to
6e065b9
Compare
Commit 14f2f84 does more than just moving code around. It seems to completely replace the |
The previous implementation was quite opinionated, e.g. without taking numbers into account. For our library, I have opted for a general approach. |
e4319e4
to
0f585f7
Compare
af4d8d1
to
b1bc41e
Compare
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.
Just a few small things I noticed. I think we can start doing the actual move soon. What's the plan here? There seems to be no clear pattern like pkg/
will be moved as a whole, is each sub-package planned to either be moved or kept here (hence also the one "is this supposed to be moved?" question)?
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.
Looks fine for me now. (Not formally clicking approve here as you wanted to still clean up the commit history. And maybe even do the switchover to the library in this PR?)
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.
Now same level of approval from my side as in #747 (review):
Looks fine for me now. (Not formally clicking approve here as you wanted to still clean up the commit history. And maybe even do the switchover to the library in this PR?)
I cleaned up the commit history and switched to using |
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.
Fine for me now. At least on the "does not seem to break anything" level. And I wouldn't go into more clean this up side-quests here unless it fixes something that's worse than the current state in Icinga DB. This PR is huge and cumbersome to work with already.
Once you've approved, I'll force the push to main and tag it as version 1.0.0 and change
go.mod
here accordingly.
If in doubt, it could also be tagged as v0.1.0, then do some more few PRs in the new repo and then make it a 1.0.
`ColumnMap` provides a cached mapping of structs exported fields to their database column names. By default, all exported struct fields are mapped to their database column names using snake case notation. The `-` (hyphen) directive for the db tag can be used to exclude certain fields. Since `ColumnMap` uses cache, the returned slice MUST NOT be modified directly.
Yeah, I started with |
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 found one last thing in the new library that should be changed, otherwise this LFTM!
Not really relevant for Icinga DB, will be fixed and become a v0.2.0. |
Closes #654