1
0
mirror of https://github.com/Unleash/unleash.git synced 2024-12-22 19:07:54 +01:00
unleash.unleash/src/lib/db/addon-store.ts

141 lines
4.1 KiB
TypeScript
Raw Normal View History

import EventEmitter from 'events';
import { Logger, LogProvider } from '../logger';
import { IAddon, IAddonDto, IAddonStore } from '../types/stores/addon-store';
import metricsHelper from '../util/metrics-helper';
import { DB_TIME } from '../metric-events';
import NotFoundError from '../error/notfound-error';
import { Db } from './db';
const COLUMNS = [
'id',
'provider',
'enabled',
'description',
'parameters',
'events',
'projects',
'environments',
OpenAPI: addon operations (#3421) This PR updates the OpenAPI schemas for all the operations tagged with "addons". In doing so, I also uncovered a few bugs and inconsistencies. These have also been fixed. ## Changes I've added inline comments to the changed files to call out anything that I think is worth clarifying specifically. As an overall description, this PR does the following: Splits `addon-schema` into `addon-schema` and `addon-create-update-schema`. The former is used when describing addons that exist within Unleash and contain IDs and `created_at` timestamps. The latter is used when creating or updating addons. Adds examples and descriptions to all relevant schemas (and their dependencies). Updates addons operations descriptions and response codes (including the recently introduced 413 and 415). Fixes a bug where the server would crash if it didn't recognize the addon provider (test added). Fixes a bug where updating an addon wouldn't return anything, even if the API said that it would. (test added) Resolves some inconsistencies in handling of addon description. (tests added) ### Addon descriptions when creating addons, descriptions are optional. The original `addonSchema` said they could be `null | string | undefined`. This caused some inconsistencies in return values. Sometimes they were returned, other times not. I've made it so that `descriptions` are now always returned from the API. If it's not defined or if it's set to `null`, the API will return `description: null`. ### `IAddonDto` `IAddonDto`, the type we used internally to model the incoming addons (for create and update) says that `description` is required. This hasn't been true at least since we introduced OpenAPI schemas. As such, the update and insert methods that the service uses were incompatible with the **actual** data that we require. I've changed the type to reflect reality for now. Assuming the tests pass, this **should** all be good, but I'd like the reviewer(s) to give this a think too. --------- Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
2023-04-18 12:50:34 +02:00
'created_at',
];
const TABLE = 'addons';
export default class AddonStore implements IAddonStore {
private db: Db;
private logger: Logger;
private readonly timer: Function;
constructor(db: Db, eventBus: EventEmitter, getLogger: LogProvider) {
this.db = db;
this.logger = getLogger('addons-store.ts');
this.timer = (action) =>
metricsHelper.wrapTimer(eventBus, DB_TIME, {
store: 'addons',
action,
});
}
destroy(): void {}
async getAll(query = {}): Promise<IAddon[]> {
const stopTimer = this.timer('getAll');
const rows = await this.db.select(COLUMNS).where(query).from(TABLE);
stopTimer();
return rows.map(this.rowToAddon);
}
async get(id: number): Promise<IAddon> {
const stopTimer = this.timer('get');
return this.db
.first(COLUMNS)
.from(TABLE)
.where({ id })
.then((row) => {
stopTimer();
if (!row) {
throw new NotFoundError('Could not find addon');
} else {
return this.rowToAddon(row);
}
});
}
async insert(addon: IAddonDto): Promise<IAddon> {
const stopTimer = this.timer('insert');
// eslint-disable-next-line @typescript-eslint/naming-convention
const rows = await this.db(TABLE).insert(this.addonToRow(addon), [
'id',
'created_at',
]);
stopTimer();
// eslint-disable-next-line @typescript-eslint/naming-convention
const { id, created_at } = rows[0];
OpenAPI: addon operations (#3421) This PR updates the OpenAPI schemas for all the operations tagged with "addons". In doing so, I also uncovered a few bugs and inconsistencies. These have also been fixed. ## Changes I've added inline comments to the changed files to call out anything that I think is worth clarifying specifically. As an overall description, this PR does the following: Splits `addon-schema` into `addon-schema` and `addon-create-update-schema`. The former is used when describing addons that exist within Unleash and contain IDs and `created_at` timestamps. The latter is used when creating or updating addons. Adds examples and descriptions to all relevant schemas (and their dependencies). Updates addons operations descriptions and response codes (including the recently introduced 413 and 415). Fixes a bug where the server would crash if it didn't recognize the addon provider (test added). Fixes a bug where updating an addon wouldn't return anything, even if the API said that it would. (test added) Resolves some inconsistencies in handling of addon description. (tests added) ### Addon descriptions when creating addons, descriptions are optional. The original `addonSchema` said they could be `null | string | undefined`. This caused some inconsistencies in return values. Sometimes they were returned, other times not. I've made it so that `descriptions` are now always returned from the API. If it's not defined or if it's set to `null`, the API will return `description: null`. ### `IAddonDto` `IAddonDto`, the type we used internally to model the incoming addons (for create and update) says that `description` is required. This hasn't been true at least since we introduced OpenAPI schemas. As such, the update and insert methods that the service uses were incompatible with the **actual** data that we require. I've changed the type to reflect reality for now. Assuming the tests pass, this **should** all be good, but I'd like the reviewer(s) to give this a think too. --------- Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
2023-04-18 12:50:34 +02:00
return this.rowToAddon({ id, createdAt: created_at, ...addon });
}
async update(id: number, addon: IAddonDto): Promise<IAddon> {
const rows = await this.db(TABLE)
.where({ id })
OpenAPI: addon operations (#3421) This PR updates the OpenAPI schemas for all the operations tagged with "addons". In doing so, I also uncovered a few bugs and inconsistencies. These have also been fixed. ## Changes I've added inline comments to the changed files to call out anything that I think is worth clarifying specifically. As an overall description, this PR does the following: Splits `addon-schema` into `addon-schema` and `addon-create-update-schema`. The former is used when describing addons that exist within Unleash and contain IDs and `created_at` timestamps. The latter is used when creating or updating addons. Adds examples and descriptions to all relevant schemas (and their dependencies). Updates addons operations descriptions and response codes (including the recently introduced 413 and 415). Fixes a bug where the server would crash if it didn't recognize the addon provider (test added). Fixes a bug where updating an addon wouldn't return anything, even if the API said that it would. (test added) Resolves some inconsistencies in handling of addon description. (tests added) ### Addon descriptions when creating addons, descriptions are optional. The original `addonSchema` said they could be `null | string | undefined`. This caused some inconsistencies in return values. Sometimes they were returned, other times not. I've made it so that `descriptions` are now always returned from the API. If it's not defined or if it's set to `null`, the API will return `description: null`. ### `IAddonDto` `IAddonDto`, the type we used internally to model the incoming addons (for create and update) says that `description` is required. This hasn't been true at least since we introduced OpenAPI schemas. As such, the update and insert methods that the service uses were incompatible with the **actual** data that we require. I've changed the type to reflect reality for now. Assuming the tests pass, this **should** all be good, but I'd like the reviewer(s) to give this a think too. --------- Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
2023-04-18 12:50:34 +02:00
.update(this.addonToRow(addon))
.returning(COLUMNS);
if (!rows) {
throw new NotFoundError('Could not find addon');
}
OpenAPI: addon operations (#3421) This PR updates the OpenAPI schemas for all the operations tagged with "addons". In doing so, I also uncovered a few bugs and inconsistencies. These have also been fixed. ## Changes I've added inline comments to the changed files to call out anything that I think is worth clarifying specifically. As an overall description, this PR does the following: Splits `addon-schema` into `addon-schema` and `addon-create-update-schema`. The former is used when describing addons that exist within Unleash and contain IDs and `created_at` timestamps. The latter is used when creating or updating addons. Adds examples and descriptions to all relevant schemas (and their dependencies). Updates addons operations descriptions and response codes (including the recently introduced 413 and 415). Fixes a bug where the server would crash if it didn't recognize the addon provider (test added). Fixes a bug where updating an addon wouldn't return anything, even if the API said that it would. (test added) Resolves some inconsistencies in handling of addon description. (tests added) ### Addon descriptions when creating addons, descriptions are optional. The original `addonSchema` said they could be `null | string | undefined`. This caused some inconsistencies in return values. Sometimes they were returned, other times not. I've made it so that `descriptions` are now always returned from the API. If it's not defined or if it's set to `null`, the API will return `description: null`. ### `IAddonDto` `IAddonDto`, the type we used internally to model the incoming addons (for create and update) says that `description` is required. This hasn't been true at least since we introduced OpenAPI schemas. As such, the update and insert methods that the service uses were incompatible with the **actual** data that we require. I've changed the type to reflect reality for now. Assuming the tests pass, this **should** all be good, but I'd like the reviewer(s) to give this a think too. --------- Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
2023-04-18 12:50:34 +02:00
return this.rowToAddon(rows[0]);
}
async delete(id: number): Promise<void> {
const rows = await this.db(TABLE).where({ id }).del();
if (!rows) {
throw new NotFoundError('Could not find addon');
}
}
async deleteAll(): Promise<void> {
await this.db(TABLE).del();
}
async exists(id: number): Promise<boolean> {
const stopTimer = this.timer('exists');
const result = await this.db.raw(
`SELECT EXISTS (SELECT 1 FROM ${TABLE} WHERE id = ?) AS present`,
[id],
);
const { present } = result.rows[0];
stopTimer();
return present;
}
// eslint-disable-next-line @typescript-eslint/explicit-module-boundary-types
rowToAddon(row): IAddon {
return {
id: row.id,
provider: row.provider,
enabled: row.enabled,
OpenAPI: addon operations (#3421) This PR updates the OpenAPI schemas for all the operations tagged with "addons". In doing so, I also uncovered a few bugs and inconsistencies. These have also been fixed. ## Changes I've added inline comments to the changed files to call out anything that I think is worth clarifying specifically. As an overall description, this PR does the following: Splits `addon-schema` into `addon-schema` and `addon-create-update-schema`. The former is used when describing addons that exist within Unleash and contain IDs and `created_at` timestamps. The latter is used when creating or updating addons. Adds examples and descriptions to all relevant schemas (and their dependencies). Updates addons operations descriptions and response codes (including the recently introduced 413 and 415). Fixes a bug where the server would crash if it didn't recognize the addon provider (test added). Fixes a bug where updating an addon wouldn't return anything, even if the API said that it would. (test added) Resolves some inconsistencies in handling of addon description. (tests added) ### Addon descriptions when creating addons, descriptions are optional. The original `addonSchema` said they could be `null | string | undefined`. This caused some inconsistencies in return values. Sometimes they were returned, other times not. I've made it so that `descriptions` are now always returned from the API. If it's not defined or if it's set to `null`, the API will return `description: null`. ### `IAddonDto` `IAddonDto`, the type we used internally to model the incoming addons (for create and update) says that `description` is required. This hasn't been true at least since we introduced OpenAPI schemas. As such, the update and insert methods that the service uses were incompatible with the **actual** data that we require. I've changed the type to reflect reality for now. Assuming the tests pass, this **should** all be good, but I'd like the reviewer(s) to give this a think too. --------- Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
2023-04-18 12:50:34 +02:00
description: row.description ?? null,
parameters: row.parameters,
events: row.events,
projects: row.projects || [],
environments: row.environments || [],
createdAt: row.created_at,
};
}
// eslint-disable-next-line @typescript-eslint/explicit-module-boundary-types
addonToRow(addon: IAddonDto) {
return {
provider: addon.provider,
enabled: addon.enabled,
description: addon.description,
parameters: JSON.stringify(addon.parameters),
events: JSON.stringify(addon.events),
projects: JSON.stringify(addon.projects || []),
environments: JSON.stringify(addon.environments || []),
};
}
}