API to constrain some fields of a record arbitrary

[skybrian]

Here's a rough sketch of an API that could implement an equality constraint in a way that's much more efficient than filtering:

Suppose you have two arbitraries that generate records, department and employee. We'd like to generate pairs of records with an equality constraint, similar to a SQL query:

select * from department, employee where department.id = employee.department_id

A nice API to do this might like this:

const example = department.chain((d) => {
  return fc.record({
     dept: fc.constant(d),
     emp: employee.whereEquals({department_id: d.id})
  });
});

How this might work:

• change fc.record() so it returns a subclass of Arbitrary called RecordArbitrary, which has a whereEquals() method. The class remembers the record model that was passed as the first argument to fc.record()
• The whereEquals() method returns a modified copy of the RecordArbitrary by swapping out the specified fields in the record model, replacing them with constant Arbitraries.

Ideally it would also check that the supplied value could actually have been generated by the field's arbitrary. That is, the supplied value needs to be a possible member of the set represented by the arbitrary. I believe canShrinkWithoutContext() is more-or-less a set-membership test, but it isn't always implemented, and membership can't be implemented for some arbitraries such as streams. Instead there would need to be a nonMember() check that returns true if the supplied value is definitely not a member.

More generally, though, there are other arbitraries that might contain records. For example, a constantFrom arbitrary could contain records and might usefully be narrowed by filtering the list of constants. Perhaps a oneof arbitrary could eliminate any non-records and also any record arbitraries that couldn't generate the field value.

Could this be implemented outside of fast-check? Maybe it could, using a class that contains a recordModel and has methods that create record arbitraries.

Edit: Thinking about this some more, I think a separate datatype is the right approach. Although relational databases are about sets and arbitraries also represent sets, the operations are different. It makes more sense for a RecordModel to be a datatype with a richer set of operations, that can then be converted to an arbitrary. This doesn't need to be done in fast-check.

[dubzzz]

I feel that the answer that @gruhn gave on the discussion #5022 (reply in thread) is close to what you'd need here. At the moment, there is no built-in way to describe a relationship between set of entities in order to generate them.