Open uladkasach opened 2 years ago
:thinking: - we can probably start with just treating everything as a union
e.g., still suffix each token so that we identify the type of every position of the token without explicitly considering whether its a Union or Intersection - and then when we go to output the types just treat everything as a union
this is not ideal as it removes some type saftey (i.e., if we did consider intersections, we would help notify users sooner that their query is not going to work)
but it is ideal in the sense that it is way faster to implement and way more convinient to use
lets start there - and we can create another ticket for intersections and explicit AND -vs- OR support when we need it / when the benefit is justified
OR statements are important - but not trivial to support.
the reason they're not trivial is because they open the topic that one query may attempt to use the same token in different ways:
consider the following cases
optional filter
broader search
impossible criteria
case 1 and 2 are no problem to support, just union the types
case 3 is a problem to support, because we have to intersect the types
how do we distinguish between intersection cases and union cases?:
how do we merge intersections?:
type name = string & number
=> can never satisfyok... how do we identify unions though?
OR
is the keyword()
wrapping around one or more ORs in order for us to allow ittype & type[]
ok cool
and how do we distinguish in the data model unions vs intersections?
ok so that means, when we're outputting the types
&
|
how do we handle identifying these cases then, functionally?
until#1
,until#2
this seems pretty tractable!