-
Notifications
You must be signed in to change notification settings - Fork 242
Add namespace to pins #856
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,3 @@ | ||
| BEGIN; | ||
| ALTER TABLE pins DROP COLUMN namespace; | ||
| COMMIT; |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| BEGIN; | ||
| ALTER TABLE pins ADD COLUMN namespace VARCHAR(64); | ||
| UPDATE pins SET namespace = 'ff_system'; | ||
| ALTER TABLE pins ALTER COLUMN namespace SET NOT NULL; | ||
| COMMIT; | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| ALTER TABLE pins DROP COLUMN namespace; |
| Original file line number | Diff line number | Diff line change | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,2 @@ | ||||||||||||||||||||
| ALTER TABLE pins ADD COLUMN namespace VARCHAR(64); | ||||||||||||||||||||
| UPDATE pins SET namespace = "ff_system"; | ||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you think we should we update the indexes to have I've noticed we did that elsewhere when we introduced a namespace, and I guess it should help with isolation of performance considerations between namespaces in the case of a shared DB.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As part of answering this, I think it would be good to look at this code: firefly/internal/events/aggregator.go Lines 224 to 232 in eb61c4c
If the event aggregator is to become namespace aware, then I would expect the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good catch, and I think this should be rolled into #855 where the aggregator becomes namespace-aware.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we do that without introducing yet another migration file?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, can do. We've said migrations aren't guaranteed to be stable in mainline (only between releases).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See here |
||||||||||||||||||||
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've added a
migration_considerationtag, as we've chosenff_systemreally only because it's a reserved namespace name that can be used to query these values back (definitely not because these pre-upgrade pins were all for theff_systemnamespace).So we should document that.
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.
Yea, originally I was going to leave it blank but then realized the API would give you no way to query them (and that seemed bad).
Pins were treated as "global" in 1.0, and the aggregator loop that processes pins even logs them as if they are part of
ff_system(see here), so it didn't feel terribly wrong to pickff_systemfor this purpose. But it was always a bit inaccurate, as they are specific to a namespace even if they weren't treated that way.Anyway, bit of a ramble but I agree we need to document it.