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

Create aliases for all database model IDs #310

Merged
merged 1 commit into from
Sep 13, 2023
Merged

Conversation

xinaxu
Copy link
Contributor

@xinaxu xinaxu commented Sep 13, 2023

This PR creates type aliases for IDs of all database models so that it will be easier for future refactor (i.e. switch from uint32 to uint64)

resolves #226

@xinaxu xinaxu requested a review from hannahhoward September 13, 2023 18:56
@codecov
Copy link

codecov bot commented Sep 13, 2023

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.06% 🎉

Comparison is base (9eca098) 73.89% compared to head (8151310) 73.96%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #310      +/-   ##
==========================================
+ Coverage   73.89%   73.96%   +0.06%     
==========================================
  Files         130      130              
  Lines        8065     8065              
==========================================
+ Hits         5960     5965       +5     
+ Misses       1476     1472       -4     
+ Partials      629      628       -1     
Files Changed Coverage Δ
handler/dataprep/explore.go 72.36% <ø> (ø)
handler/dataprep/piece.go 75.75% <ø> (ø)
handler/job/status.go 70.96% <ø> (ø)
model/replication.go 100.00% <ø> (ø)
scan/prepare.go 68.11% <ø> (ø)
service/dealtracker/dealtracker.go 79.54% <ø> (ø)
handler/file/push.go 54.54% <100.00%> (ø)
handler/job/pack.go 71.42% <100.00%> (ø)
migrate/migrate-dataset.go 72.28% <100.00%> (ø)
model/preparation.go 81.25% <100.00%> (ø)
... and 12 more

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link

@anjor anjor left a comment

Choose a reason for hiding this comment

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

Dind't take a super close look, but looks good!

@hannahhoward
Copy link
Contributor

hannahhoward commented Sep 13, 2023

LGTM, but why not change the handler signature's as well -- I'd like to get us using these in Motion calls as well ASAP. If we're not using semantic types in the external calls, we don't get the full benefits of this refactor -- but feel free to do a seperate PR.

@xinaxu
Copy link
Contributor Author

xinaxu commented Sep 13, 2023

The swagger data types can only specify general "integer" which is translated to int64 at the client struct. A more granular annotation is to add format(int32) and format(int64) to the annotation which is then translated to either int32 or int64 on the client side.
https://swagger.io/specification/v2/#dataTypeFormat

So I think the benefits isn't worth the effort of annotating all integer types because

  1. The unsigned part of the type info is lost
  2. By default all integers are int64 which means no refactor is needed even if we change the type from uint32 to uint64 in Singularity model package
  3. The chance of overflowing int32 is extremely low.

@xinaxu xinaxu merged commit 9c42d43 into main Sep 13, 2023
@xinaxu xinaxu deleted the xinaxu/refactor-types branch September 13, 2023 23:37
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.

Use type alias for database type uint32 and uint64
3 participants