-
-
Notifications
You must be signed in to change notification settings - Fork 229
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
🔨 (db) migrate Dataset and Source to knex #3131
Conversation
Important Auto Review SkippedAuto reviews are disabled on base/target branches other than the default branch. Please add the base/target branch pattern to the list of additional branches to be reviewed in the settings. Please check the settings in the CodeRabbit UI or the To trigger a single review, invoke the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
Current dependencies on/for this PR:
This stack of pull requests is managed by Graphite. |
51be3d9
to
92618af
Compare
605992e
to
ce15753
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.
Thanks a lot for test driving the knex approach! This looks very good overall. There are two things that I would change on the db-types PR learning from this and two things I'd ask you to change.
The two changs I'd like to see to this PR is:
- not make the knex instance optional in the knexRaw and knexRawFirst helper functions
- and to wrap all API functions we touch in a transaction scope even if we only read data as we go through them. The reasoning here is that we want reads to be consistent and it's probably better to just implement a standard pattern everywhere rather than having to evaluate if it is necessary each time.
The two things I'll change on the other PR are:
- bump the knex version so that we can create readyOnly transactions which are a bit more performant than generic ones
- add a migration to make name on datasets mandatory rather than nullable
db/db.ts
Outdated
str: string, | ||
params?: any[], | ||
knex?: Knex<any, any[]> | ||
): Promise<TRow[]> => (await (knex ?? knexInstance()).raw(str, params ?? []))[0] |
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 understand that this is convenient but I really think we should only get the knexInstance at the top level entry point and not implicitly in a helper function. This stuff can lead to some nested code using the global knex instance where it actually should be using the knex instance that is handed down from the transaction scope.
Of course in theory you could also just call knexInstance() in a nested utility funciton but then this is an explicit call that is easy to find via grep.
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.
So I'm strongly in favour of making the knex parameter not optional
db/db.ts
Outdated
export const knexRawFirst = async <TRow = unknown>( | ||
str: string, | ||
params?: any[], | ||
knex?: Knex<any, any[]> |
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.
Dito here of course
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.
Thanks a lot for test driving the knex approach! This looks very good overall. There are two things that I would change on the db-types PR learning from this and two things I'd ask you to change.
The two changs I'd like to see to this PR is:
- not make the knex instance optional in the knexRaw and knexRawFirst helper functions
- and to wrap all API functions we touch in a transaction scope even if we only read data as we go through them. The reasoning here is that we want reads to be consistent and it's probably better to just implement a standard pattern everywhere rather than having to evaluate if it is necessary each time.
The two things I'll change on the other PR are:
- bump the knex version so that we can create readyOnly transactions which are a bit more performant than generic ones
- add a migration to make name on datasets mandatory rather than nullable
486942e
to
ce49d9f
Compare
a834c76
to
435d84a
Compare
67b9b99
to
c28f073
Compare
435d84a
to
a35b059
Compare
c28f073
to
253ae3b
Compare
a35b059
to
009d6fb
Compare
This PR has had no activity within the last two weeks. It is considered stale and will be closed in 3 days if no further activity is detected. |
009d6fb
to
8c71da0
Compare
c538a40
to
92444de
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.
Good to go I think!
Before the name
field was made non-nullable in the db, I added a check to make sure a dataset name
is given. We could get rid of that now :)
db/model/Dataset.ts
Outdated
return dataPackage | ||
} | ||
|
||
export function isDatasetWithName( |
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 think we can remove this check (and all its references) now since we've made the dataset name non-nullable in the db.
adminSiteServer/apiRouter.ts
Outdated
}) | ||
|
||
try { | ||
await removeDatasetFromGitRepo(dataset.name, dataset.namespace, { | ||
await removeDatasetFromGitRepo(dataset.name!, dataset.namespace, { |
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.
Again, one of my changes... The '!' shouldn't be necessary anymore
Makes the
Dataset
andSource
TypeORM classes obsolete by switching db access to knexThis PR does not do any clean-up, e.g. SQL queries in the router files are not moved, although they ultimately should live in the
db
folderI added two helper functions that can be used as drop-in replacements for
queryMysql
andmysqlFirst
that are often used in our codebase,knexRaw
andknexRawFirst
(both live indb.ts
)Routes that I could easily test are tested, but not all of the code is!
@danyx23 let me know if this is how you imagined it, or if I should do anything differently.
@coderabbitai ignore