-
Notifications
You must be signed in to change notification settings - Fork 18
feat: add event informant and stream cid (part 4) #484
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
feat: add event informant and stream cid (part 4) #484
Conversation
0adc56f to
e1d6233
Compare
e1d6233 to
46a78fe
Compare
52c49ec to
395e326
Compare
46a78fe to
d4a0c1f
Compare
1bc7d0c to
a466a1e
Compare
d4a0c1f to
30a0e2e
Compare
f04ee57 to
ec2c8b4
Compare
event-svc/src/event/service.rs
Outdated
| /// In the future, we will need to do more event validation (verify all EventID pieces, hashes, signatures, etc). | ||
| pub(crate) async fn parse_discovered_event( | ||
| item: &ReconItem<EventId>, | ||
| source: Option<String>, |
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.
why is source optional? Aren't all events going to have a source?
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.
not when we insert from a migration.
API: self
Generated time event: self
Recon: the NodeId.try_from_peer_id(peer_id)
migration: None
| stream_cid: Cid, | ||
| event_cid: Cid, | ||
| event: unvalidated::Event<Ipld>, | ||
| source: Option<String>, |
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 see we add stream_cid, source, and anchored to the sql table, but we're only adding the first two here. Does this need to take anchored also?
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.
We just took out anchored. We were planning to use it in part 5 but are not doing so anymore.
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.
in that case do we still need it in the sql table?
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 it was removed, unless "it" is not anchored 😅.. init_cid and informant were added
| async fn insert_many( | ||
| &self, | ||
| items: &[ReconItem<Self::Key>], | ||
| // the recon::Store trait is shared between InterestService and EventService but only events track a source. |
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.
don't interests have a source too? Could this be unified?
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.
As we discussed in standup, we do not currently have a use case for storing the source of an interest. We can add support for this when needed.
| -- Add up migration script here | ||
|
|
||
| -- The CID of the Init Event for the stream | ||
| ALTER TABLE ceramic_one_event ADD COLUMN init_cid BLOB DEFAULT NULL; |
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.
how will this get backfilled for events that were created before this field was present in the db?
Really ideally this column would be non-nullable and always required, but that makes the upgrade path trickier
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.
Right now we're only using this field while generating Time Events, which will only happen for events that also have the informant populated. We should never have events with an informant and without a init_cid. This means that the init_cid being missing is ok from the self-anchoring perspective, but it does still need to be populated so that we can support things like looking up events for a stream.
Created a ticket for this.
one/src/migrations.rs
Outdated
| let network = opts.network.to_network(&opts.local_network_id)?; | ||
| let db_opts: DBOpts = (&opts).into(); | ||
| let sqlite_pool = db_opts.get_sqlite_pool().await?; | ||
| // the source did:key is none for migrations as we don't know the source node. |
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.
hmm, couldn't an argument be made to just consider this local node the source? This is the first node bringing this data into the Recon network after all...
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.
Maybe, maybe not. It was likely created and anchored by someone else before the migration. e.g. the old node you are migrating from.
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.
right, but that's almost certainly "logically" the same node. Ie operated by the same person, serving the same purpose/application, and directly replacing the old node in every way. What's the harm in considering the migrated event as having this node as the source?
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.
If these events are considered originating locally, they might be considered (newly) eligible for self-anchoring.
During migration, it would probably be safe to assume that any events that needed to be anchored were already anchored.
dav1do
left a comment
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.
A few more questions but overall it's looking good. Happy to get on a call to talk through them if it helps speed it up. And the PR name is out of date now - not sure how to comment on that directly :).
0a18a1a to
9faee13
Compare
| @@ -0,0 +1,9 @@ | |||
| -- Add up migration script 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.
looks like the file names for these migrations probably should be updated in a follow-up since they don't really reflect what is happening in them anymore
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.
e.g. they don't add "anchored" anymore
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.
Yes, we fixed this in part 5.
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.
Oh dang, I didn't notice that. Unfortunately, I don't think you can change a migration name after it's been applied somewhere.. pretty sure it's a unique constraint or part of the hash with how sqlx manages them. We can try it but iirc it will error saying something like migration with name x has previously been applied but is missing.
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.
presumably so long as we fix this before it goes out in a release it's fine?
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.
well, it's in a prerelease now and if anyone has run main locally they'll need to manually adjust their db (or delete the file). plus any test nodes we're running it on... my opinion is that's it a bummer but isn't worth the risk/hassle. I don't really pay attention to migration names though (clearly) and just look at the schemas.
This PR includes the changes for storing the source node DID and stream Init Event CID in the Event Store.
This is needed to be able to filter out events submitted to the C1 node via API so that only our events are anchored.