search

ubiquity-os / ubiquity-os-kernel

1 stars 19 forks source link

feat: migration files for the database schema #33

Closed gentlementlegen closed 8 months ago

gentlementlegen commented 8 months ago

Resolves https://github.com/ubiquity/ubiquibot/issues/919

It is done in this repository as the issue was opened in the old Ubiquibot repo which should not be relevant soon. The schema is a copy of the one currently used by wfzpewmlyiozupulbuur Supabase project.

The changes are already applied in the database, these migrations just reflect its current state.

github-actions[bot] commented 8 months ago

Unused dependencies (4)

Filename dependencies
package.json @octokit/webhooks-types
create-cloudflare
octokit
universal-github-app-jwt

Unused devDependencies (4)

Filename devDependencies
package.json @mswjs/data
esbuild
eslint-config-prettier
eslint-plugin-prettier

Unlisted dependencies (9)

Filename unlisted
src/github/github-client.ts @octokit/corebr/>`@octokit/types`<br/@octokit/plugin-paginate-restbr/>`@octokit/plugin-rest-endpoint-methods`<br/@octokit/plugin-retrybr/>`@octokit/plugin-throttling`<br/@octokit/auth-app
src/github/github-event-handler.ts @octokit/auth-app
src/github/utils/config.ts yaml

Unlisted binaries (5)

Filename binaries
package.json lsof
awk
.github/workflows/build.yml build
.github/workflows/bun-testing.yml i
.github/workflows/cspell.yml format:cspell
whilefoo commented 8 months ago

Every plugin will have its own DB and the kernel just calls plugins so it doesn't need any DB

gentlementlegen commented 8 months ago

Every plugin will have its own DB and the kernel just calls plugins so it doesn't need any DB

@whilefoo Understood, then what will happen with the current db, plain delete? We can close this PR and just validate the issue as completed if you want, changes are already applied on the db side.

0x4007 commented 8 months ago

The only useful data from the current database isn't really even worth migrating. It's just the wallet data. Instead we can just force everybody to re-register.

However we may also need to figure some type of standardized way to bus data from plugins to other plugins.

For example:

Wallet registration plugin /wallet stores wallets

Permit generation requires wallet data.

Technically we could make it the same plugin with two different intended entry points though. One for the slash command (comment created event) and then one to generate permits (invoked as part of a chain of other plugins, originally from issue closed as complete)

This might be the easiest way forward in the short term. In the longer term we can probably take inspiration from how Amazon web services was formed. Basically leadership forced the team to build internal systems with standardized modules and interfaces. Then they made those interfaces public.

rndquu commented 8 months ago

This PR corresponds to 2 bot plugins:

I don't want to close this PR without merging since these DB migrations will eventually end up in plugins' DB instances. I think the best thing we can do right now is to merge this PR into the old bot's instance at https://github.com/ubiquity/ubiquibot

gentlementlegen commented 8 months ago

This PR corresponds to 2 bot plugins:

I don't want to close this PR without merging since these DB migrations will eventually end up in plugins' DB instances. I think the best thing we can do right now is to merge this PR into the old bot's instance at https://github.com/ubiquity/ubiquibot

I am fine with that, I will move the PR to the other repository.

gentlementlegen commented 8 months ago

Pull request moved to https://github.com/ubiquity/ubiquibot/pull/923