Unify PatchSchema and PatchCollection

[AndrewSisley]

I think it would be nicer if there is just one entry point for this:

testUtils.SchemaPatch{
	Patch: `
		[
			{ "op": "add", "path": "/Schema/Users/Fields/-", "value": {"Name": "name", "Kind": "String"} },
	                // Make the second collection the active one by moving its name from the first to the second
			{ "op": "move", "from": "/Collections/1/Name", "path": "/Collections/2/Name" }
		]
	`,
},

This may be fairly fiddly to achieve however, for example in the above collection 2 does not exist yet. Have a long think about the dev-ex of this.

for example in the above collection 2 does not exist yet

Although, this problem will exist anyway once we unlock the adding of collections/schema via patches anyway, and might actually already be a problem when adding fields (I cant remember).

[fredcarle]

Since we are trying to separate the Schema and Collection within the code base, wouldn't unifying this go against what has been done already?

[AndrewSisley]

Since we are trying to separate the Schema and Collection within the code base, wouldn't unifying this go against what has been done already?

I dont think so, it is one end point, but they are very clearly separate paths (Schema vs Collection). It just means users can submit many commands in a single patch (including test commands).

The name of the endpoint could be PatchDescriptions or something - It could even be extended later to allow the uploading (and modification?) of ACP policies and other stuff.

My biggest concern here is probably that it could obfuscate the order of operations - e.g. to allow the example in the description, schema would need to be processed before collections

[fredcarle]

You're right. It's the same endpoint but the path is the differentiator. Thanks for pointing that out.