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

Configure blob and schema replication via dedicated config flags #564

Open
sandreae opened this issue Sep 18, 2023 · 4 comments
Open

Configure blob and schema replication via dedicated config flags #564

sandreae opened this issue Sep 18, 2023 · 4 comments

Comments

@sandreae
Copy link
Member

sandreae commented Sep 18, 2023

System schemas sometimes require more specialised configuration logic compared to application schema. Currently we include all schema we want to replicate in an allowed_schema_ids list which includes both application and system schema ids, which isn't always that intuitive. Using dedicated config flags for configuring replication of system schema could help bring clarity.

schema definition replication

Add a flag for whether we want to replicate schema definitions.

replicate_schema_definition = true

This would result in our TargetSet including both schema_definition_v1 and schema_field_definition_v1.

blob replication

Globally configure (phase 1)

Add fields for configuring behaviour around blobs globally (would apply to all schema the node allows)

allow_schema_ids = ["photos_0020...."]
replicate_blob_meta = true
replicate_blob_data = false

The resulting TargetSet would contain blob_v1 but not blob_piece_v1 schema ids.

Fine grained control per schema (phase 2)

Configure on a per-schema basis

[[allow_schema_ids]]
id = "user_profile_0020a01fe..."
blob_meta = true
blob_data = true

[[allow_schema_ids]]
id = "huge_video_files_0020a01fe..."
blob_meta = true
blob_data = false

There would need to be multiple resulting TargetSets each with a dedicated replication session. The target sets would each contain one "parent" (application) schema id and then blob_v1 and blob_piece_v1 depending on their particular configuration.

Linked to #561 the blob_data field could later contain the on device storage space allotted to that blob type ✊

@adzialocha
Copy link
Member

adzialocha commented Sep 21, 2023

What happens if I write:

blob_meta = false
blob_data = true

..? It's a stupid example, but maybe we can not express the config as booleans but as "modes"? Something like this:

blobs_replication = "only_related_meta" | "only_related" | "*"

@sandreae
Copy link
Member Author

Oh yeh, I really like the idea of having "modes" 👍

@sandreae
Copy link
Member Author

Thought being able to configure "max_blob_size" would also be really good. As you would if you had a server accepting uploads.

@adzialocha
Copy link
Member

Thought being able to configure "max_blob_size" would also be really good. As you would if you had a server accepting uploads.

Yeah! That's a nice addition, don't think they contradict each other

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

No branches or pull requests

2 participants