Add actors table and actor GraphQL API - #47
Conversation
3e7a1f0 to
9ce4e31
Compare
|
I have some comments related to actor schema. I see only followee/follower counters not actual follow relationship among actors. I don't think |
I haven't fully implemented the follow-related features yet since they weren't part of the current goal. I've kept the terminology as consistent as possible with the Hackers' Pub codebase. Personally, I also prefer the term "followee" because it provides a clear contrast to "follower." |
Prompts: Actor 를 위한 GraphQL 빌더를 추가했습니다. @packages/graphql/src/actor.test.ts 에 이를 위한 테스트를 생성해주세요. 파일 추가 직후 `mise run fmt` 로 라이선스를 추가하세요. 최소한 다음과 같은 테스트가 필요합니다. - 액터 생성 - 로컬 액터 조회 - 리모트 액터 조회 Assisted-by: Codex:gpt-5-6-sol
9ce4e31 to
237fe6e
Compare
| } | ||
|
|
||
| builder.mutationFields((t) => ({ | ||
| genActors: t.field({ |
There was a problem hiding this comment.
I think to use prefix create over gen is more consistent else other success or fail messages/interface/types should be GenActorsSuccess or something It's kinda confusing if you reserve createActors for something else then well it's another story
There was a problem hiding this comment.
const genActorMutation = graphql`
mutation genActorMutation(
$instance: ID! $size: Int!
) {
genActors(instance: $instance, size: $size) {
resultType: __typename
... on CreateActorsSuccess {
actors {
username
}
}
... on CreateActorsError {
type
message
}
}
}
)`using two different verbs to represent one same thing is not ideal imo
There was a problem hiding this comment.
I named it genActors in the sense that it generates them without the need to specify every single attribute one by one. For the resulting CreateActorsResult, I used the more general Create because other mutations for creating Actors might arise, and I wanted to give it a versatile name since I thought it would be better to consolidate into one rather than creating a result type every time. Does it seem awkward?
There was a problem hiding this comment.
Not awkward, but bit confusing when i name some related variables. also i don't think there would be another actor creating api for now tho like what else... hmm...
There was a problem hiding this comment.
also i would avoid using shorthand like 'gen' than 'generate' but it's bit personal (fyi)
Apply the same shape to actors that 09be000 applied to instances: - Move the remote_actors columns (iri, inboxUrl, outboxUrl, and the optional followers/followees/featured/profile/avatar/header URLs) into actors and drop the remote_actors table. iriUrl is renamed to iri and stays unique. - Drop the location enum column and the (id, location) composite FK/CHECK pairs. Local actors are identified by actors.localId, a nullable unique FK to local_actors.id with cascade delete, which inverts the previous local_actors.id -> actors.id dependency. local_actors keeps only id, avatar, and header. - Replace the actor migration. The old 20260803204536 migration created actors with the "location" type that the later 20260818 migration drops, so it could not apply on a fresh database and it was never on main. The new migration is regenerated from the current snapshot. - Store local actor URLs at creation time. genActors inserts local_actors first, then actors with the URLs expanded from the URI templates using instances.host, and joins local_instances via instances.localId. avatarUrl and headerUrl start as NULL. - Simplify the Actor GraphQL type to expose stored columns, keep handle as a field-level select on instance.host, and add uuid, created, and a nullable local: LocalActor relation. Replace the CreateActors node with Actor in CreateActorsSuccess.actors. - Fix the Instance.actors connection, whose resolveNode returned the instanceId instead of the actor. - Update the actor tests for the new seeds, fields, and assertions. AI provenance: Claude Code was asked to analyze the instance merge in 09be000 and write a plan applying the same approach to actors, covering the schema, migration, GraphQL API, and tests; it found that the branch no longer type-checked after the rebase and that the old actor migration depended on a dropped enum type. Codex implemented the changes from that plan. Claude Code then reviewed the diff against the plan, ran tsc for each package, and ran the test suite. The human contributor has read and reviewed both the plan and the implementation, and directly modified some of the designs. They validated the generated migration SQL and performed local checks and tests. Assisted-by: Claude Code:claude-fable-5 Assisted-by: Codex:gpt-5.6-sol
| host: "test-instance.drfed.org", | ||
| }, | ||
| local: { | ||
| avatar: "avatar.png", |
There was a problem hiding this comment.
Maybe we don't need avatars and headers for users ? I don't think it's relevant to interop debugging
There was a problem hiding this comment.
may not activitypub.academy supports that. just wondering your thoughts
There was a problem hiding this comment.
Sometimes profile image updates aren't being sent between instances. We need to test for that, I think?
3 participants
Resolves #6.
Add
actorstable and actor GraphQL API to create and reads.To merge this PR, #44 must be preceded.
Before starting the server, please remove the existing
.pgdata/to clean up the DB.Assisted-by: Codex:gpt-5-6-sol to generate test and implement merging
remoteActorsintoactors.Assisted-by: Claude Code:claude-fable-5 to plan merging
remoteActorsintoactors.