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

Notification migration #2063

Open
wants to merge 28 commits into
base: main
Choose a base branch
from
Open

Notification migration #2063

wants to merge 28 commits into from

Conversation

PooyaRaki
Copy link
Contributor

Summary

Add compatibility between Notification V1 and Notification V2. Integrate Notification V2 methods into Notification V1 to begin populating the database in advance of the data migration, ensuring clients can transition to V2 seamlessly without any changes on their end.

Changes

  • Integrate V2 methods within the V1 controller.
  • Refactor the V2 repository using TypeORM.

@PooyaRaki PooyaRaki force-pushed the notificationMigration branch 4 times, most recently from 19e7c42 to a28bfab Compare November 4, 2024 12:07
@PooyaRaki PooyaRaki marked this pull request as ready for review November 4, 2024 12:16
@PooyaRaki PooyaRaki requested a review from a team as a code owner November 4, 2024 12:16
src/routes/notifications/v1/notifications.controller.ts Outdated Show resolved Hide resolved
src/routes/notifications/v1/notifications.controller.ts Outdated Show resolved Hide resolved
import { z } from 'zod';

export const UpsertSubscriptionsDtoSafeSchema = z.object({
chainId: z.string(),
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
chainId: z.string(),
chainId: NumericStringSchema,

Copy link
Contributor Author

Choose a reason for hiding this comment

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

src/routes/notifications/v1/notifications.controller.ts Outdated Show resolved Hide resolved
src/routes/notifications/v1/notifications.controller.ts Outdated Show resolved Hide resolved
Copy link
Member

@iamacook iamacook left a comment

Choose a reason for hiding this comment

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

All of my comments can be tackled in a follow up as they are validation focused. I would suggest we add schema tests for those implemented here as well.

migrations/1726752966034-notification.ts Show resolved Hide resolved
migrations/1726752966034-notification.ts Show resolved Hide resolved
migrations/1726752966034-notification.ts Show resolved Hide resolved
Comment on lines 79 to 96
const safeV2: {
authPayload: AuthPayload;
upsertSubscriptionsDto: UpsertSubscriptionsDto & {
safes: Array<UpsertSubscriptionsSafesDto>;
signature: `0x${string}`;
};
Copy link
Member

Choose a reason for hiding this comment

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

Could we extract this to a type, instead of typing it inline?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I totally agree. Since we usually define types inline, I did it this way to keep it consistent. Do you think we should consider creating an external type for it?

Copy link
Member

Choose a reason for hiding this comment

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

You should be able to extract this type from the controller using utility types, therefore keeping the controller as the SSOT.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As we discussed, I find heavy use of utility types makes the code extremely hard to read. However, I’d be happy to make the change if you could provide a code snippet as an example.

Copy link
Member

Choose a reason for hiding this comment

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

No strong opinion here, but I'd prefer to use utility types so we can have a SSOT as Aaron suggests 🙂 Feel free to keep the current implementation if you prefer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done
5e5999d

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.

3 participants