Backups: subcommands, prefix-filtering, parsing #313
Conversation
jzelinskie
force-pushed
the
backup-prefix
branch
from
7ffff64 to
29a70ad
Compare
internal/cmd/backup.go
Outdated
|
|
||
| func hasRelPrefix(rel *v1.Relationship, prefix string) bool { | ||
| // Skip any relationships without the prefix on either side. | ||
| return strings.HasPrefix(rel.Resource.ObjectType, prefix) || |
There was a problem hiding this comment.
I wonder if we want to do this for either side, or if we only want to include relationships that originate on the prefix side...
There was a problem hiding this comment.
Either way you need the definition, right? I wonder if there's something from SpiceDB's reachability analysis that could be used here for maximum correctness.
There was a problem hiding this comment.
True, but since this is the relationships filter, you might be missing the definitions for things that are referenced... e.g. a:b#view->prefix/c:d, you won't necessarily have the definition for a
There was a problem hiding this comment.
I used the typesystem to guarantee that our generated schema is comprehensive, this means that if there was any non-prefixed dependencies, we would throw a failure.
We can circle back later and support for discovering the dependencies.
jzelinskie
force-pushed
the
backup-prefix
branch
2 times, most recently
from
4869932 to
8403b5d
Compare
if one of the batches sent fails, zed will hide the underlying error and just report EOF. The gRPC backend will report EOF as part of an error, which will have to eb retrieved via CloseAndRecv(). A common error that surfaced as EOF was duplicate relationships after reimporting the same backup file. Closes #310. Co-authored-by: Víctor Roldán Betancort <vroldanbet@authzed.com>
jzelinskie
force-pushed
the
backup-prefix
branch
from
8403b5d to
cbbeaad
Compare
jzelinskie
force-pushed
the
backup-prefix
branch
from
534c17e to
099fa38
Compare
jzelinskie
force-pushed
the
backup-prefix
branch
from
ded434c to
0bb1a27
Compare
also does some minor refactoring on the function to make it testable and easier to follow
also DRY creation of decoder, and align error handling of io.Closer values
| schema = string(missingAllowedTypes.ReplaceAll([]byte(schema), []byte("\n/* deleted missing allowed type error */"))) | ||
| schema = string(shortRelations.ReplaceAll([]byte(schema), []byte("\n/* deleted short relation name */"))) | ||
|
|
||
| compiledSchema, err := compiler.Compile(compiler.InputSchema{Source: "schema", SchemaString: schema}, compiler.SkipValidation()) |
There was a problem hiding this comment.
oddly, we skip validation on the input but we do not do it on the output. That's going to cause the call to fail.
E.g. your input schema is invalid because the prefix is too short. It will be successfully compiled, but after filtering the second compilation pass will fail.
There was a problem hiding this comment.
let's not block on this since at least is a safe strategy. I think the scenario I reproduced with a test was precisely what the regexes above fix, so it may be difficult to actually make it err
| func writeRelationshipsFromArgsOrStdin(cmd *cobra.Command, args []string) error { | ||
| if ok := isArgsViaFile(os.Stdin) && len(args) == 0; ok { | ||
| return nil | ||
| func StdinOrExactArgs(n int) cobra.PositionalArgs { |
There was a problem hiding this comment.
yeah i should probably throw this into cobrautil, haha
vroldanbet
force-pushed
the
backup-prefix
branch
from
6d70225 to
378d545
Compare
This change
zed $noun $verbstructure--prefix-filterflag to commands to filter schemas and relationships from backup/restore/parsingzed backup parse-schema,zed backup parse-revision,zed backup parse-relationshipscommands to inspect backup files