Skip to content

Conversation

THE-BRAHMA
Copy link

@THE-BRAHMA THE-BRAHMA commented Sep 5, 2025

This PR introduces optional_resource_ids field to RelationshipFilter, enabling bulk relationship reads in a single API call.

After: Single bulk call

const namespaces = await spicedb.readRelationships({
  relationship_filter: {
    resource_type: "document",
    optional_resource_ids: ["DocumentA", "DocumentB", "DocumentC"],
    optional_relation: "parent"
  }
});

Implementation Details

Changes Made

  1. Validation Layer: Added counter-based mutual exclusion validation ensuring only one of optional_resource_id, optional_resource_id_prefix, or optional_resource_ids can be specified

  2. Filter Conversion: Updated RelationshipsFilterFromPublicFilter() to handle the new bulk field and convert it to internal OptionalResourceIds []string

  3. Database Optimization: Leverages existing FilterToResourceIDs() function that generates optimized IN clause queries

  4. Comprehensive Testing: Added test cases covering single IDs, multiple IDs, error scenarios, and mutual exclusion validation

Compatibility

  • Backward Compatible: Existing optional_resource_id usage unchanged
  • All Datastores: Works universally across PostgreSQL, MySQL, CockroachDB, Spanner, and MemDB
  • Validation: Prevents conflicting field usage with clear error messages

Testing

go test ./pkg/datastore -v -run TestRelationshipsFilterFromPublicFilter
go test ./internal/services/v1 -v -run TestValidateRelationshipsFilter

Related Issues

Addresses the bulk relationship reading capability discussed in #2160

Checklist

  • Implementation follows existing patterns
  • Counter-based validation prevents field conflicts
  • Comprehensive test coverage added
  • Works across all supported datastores
  • Maintains backward compatibility

@THE-BRAHMA THE-BRAHMA requested a review from a team as a code owner September 5, 2025 11:43
@github-actions github-actions bot added area/api v1 Affects the v1 API area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools) labels Sep 5, 2025
@josephschorr
Copy link
Member

@THE-BRAHMA Is the intention to add support to the API layer itself as well?

@THE-BRAHMA
Copy link
Author

THE-BRAHMA commented Sep 6, 2025

Yes, the API layer already supports it! No new API endpoint needed - the existing one handles both single and bulk resource IDs. Clients can now pass either a optional_resource_id or optional_resource_ids in the same RelationshipFilter
Cc @josephschorr

@tstirrat15
Copy link
Contributor

api-level support added here: authzed/api#145

@THE-BRAHMA
Copy link
Author

@josephschorr & @tstirrat15 Let me know if there is any improvement needed in this PR or is there a better way to solve this task.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api v1 Affects the v1 API area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants