github.com/ipld/go-ipld-prime@v0.21.0/schema/validate.go (about)

     1  package schema
     2  
     3  /*
     4  	Okay, so.  There are several fun considerations for a "validate" method.
     5  
     6  	---
     7  
     8  	There's two radically different approaches to "validate"/"reify":
     9  
    10  	- Option 1: Look at the schema.Type info and check if a data node seems
    11  	  to match it -- recursing on the type info.
    12  	- Option 2: Use the schema.Type{}.RepresentationNodeBuilder() to feed data
    13        into it -- recursing on what the nodebuilder already expresses.
    14  
    15  	(Option 2 also need to take a `memStorage ipld.NodeBuilder` param, btw,
    16  	for handling all the cases where we *aren't* doing codegen.)
    17  
    18  	Option 1 provides a little more opportunity for returning multiple errors.
    19  	Option 2 will generally have a hard time with that (nodebuilers are not
    20  	necessarily in a valid state after their first error encounter).
    21  
    22  	As a result of having these two options at all, we may indeed end up with
    23  	at least two very different functions -- despite seeming to do similar
    24  	things, their interior will radically diverge.
    25  
    26  	---
    27  
    28  	We may also need to consider distinct reification paths: we may want one
    29  	that returns a new node tree which is eagerly converted to schema.TypedNode
    30  	recursively; and another that returns a lazyNode which wraps things
    31  	with their typed node constraints only as they're requested.
    32  	(Note that the latter would have interesting implications for any code
    33  	which has expectations about pointer equality consistency.)
    34  
    35  	---
    36  
    37  	A further fun issue which needs consideration: well, I'll just save a snip
    38  	of prospective docs I wrote while trying to iterate on these functions:
    39  
    40  		// Note that using Validate on a node that's already a schema.TypedNode is likely
    41  		// to be nonsensical.  In many schemas, the schema.TypedNode tree is actually a
    42  		// different depth than its representational tree (e.g. unions can cause this),
    43  
    44  	... and that's ... that's a fairly sizable issue that needs resolving.
    45  	There's a couple of different ways to handle some of the behaviors around
    46  	unions, and some of them make the tradeoff described above, and I'm really
    47  	unsure if all the implications have been sussed out yet.  We should defer
    48  	writing code that depends on this issue until gathering some more info.
    49  
    50  	---
    51  
    52  	One more note: about returning multiple errors from a Validate function:
    53  	there's an upper bound of the utility of the thing.  Going farther than the
    54  	first parse error is nice, but it will still hit limits: for example,
    55  	upon encountering a union and failing to match it, we can't generally
    56  	produce further errors from anywhere deeper in the tree without them being
    57  	combinatorial "if previous juncture X was type Y, then..." nonsense.
    58  	(This applies to all recursive kinds to some degree, but it's especially
    59  	rough with unions.  For most of the others, it's flatly a missing field,
    60  	or an excessive field, or a leaf error; with unions it can be hard to tell.)
    61  
    62  	---
    63  
    64  	And finally: both "Validate" and "Reify" methods might actually belong
    65  	in the schema.TypedNode package -- if they make *any* reference to `schema.TypedNode`,
    66  	then they have no choice (otherwise, cyclic imports would occur).
    67  	If we make a "Validate" that works purely on the schema.Type info, and
    68  	returns *only* errors: only then we can have it in the schema package.
    69  
    70  */