Is there a way to create an Arbitrary that's similar to using fc.gen()?

[skybrian]

Is there some way of making an Arbitrary out of a callback that randomly generates a single example, sort of like using fc.gen()? The reason I ask is that working with individual examples seems easier when there are constraints within an example.

For context, here's a bit more about what I'm doing. I'd like to generate data that contains unique ids and foreign key constraints. For example, for a SQL database with Department and Employee tables, I might generate multiple Departments and multiple Employees within each department, where an Employee record has a department id.

It seems like generating ids first with fc.uniqueArray and then generating records would make sense, to make sure that foreign keys use an existing id.

I suppose fc.chain() would make sense here. But thinking in terms of sets (Arbitraries) seems awkward compared to writing code that creates one example at a time. When combining Arbitraries, it results in taking the cross-product by default, which isn't what I want for fields that have constraints.

[gruhn]

There are probably many ways to approach this. Let's say your database records have the following structure:

type DepartmentRow = {
  id: number
  department_name: string
}

type EmployeeRow = {
  department_id: number
  employee_name: string
}

For many-to-one relations like this it's probably easiest to generate everything together in a nested structure first:

const departmentArb = fc.record({
  id: fc.nat(),
  department_name: fc.string(),
  employees: fc.array(fc.string())
})

From that we can easily derive the flat database records:

fc.assert(
  fc.property(
    fc.array(departmentArb),
    departments => {
      const departmentRows: DepartmentRow[] = departments.map(
        ({ id, department_name }) => ({ id, department_name })
      )

      const employeeRows: EmployeeRow[] = departments.flatMap(
        ({ id, employees }) => employees.map(
          employee_name => ({ department_id: id, employee_name })
        )
      )

      console.log(departmentRows)
    }
  )
)

That doesn't guarantee yet, that department IDs are unique. As you suggested, we can use fc.uniqueArray. The problem with generating the IDs separately (i.e. fc.uniqueArray(fc.nat)) is that we might get fewer IDs than departments. But notice that uniqueArray accepts a "selector" function:

fc.uniqueArray(departmentArb, { selector: dep => dep.id })

With that, uniqueness is determined based on the id field.

Alternatively, if you can sacrifice from generality, it might be easier in some cases to just use the array indices as IDs.

[skybrian]

Interesting, thanks! The selector seems useful.

Sure, tree structures are easier. But I'm wondering about how to generalize this: suppose there are two columns that should be unique? What if, instead of generating a tree, we're generating a graph?

The way I'm thinking about this is that in relational terms, combining N independent arbitraries does a cross-product between all of them and then selects one row as the sample, in effect. This is like choosing from select * from A, B. If there's no where clause, it does a cross-product. It would be nice to be able to add constraints similar to a where clause. You could say that a.id == b.parent. Filter can do this, but very inefficiently for equality constraints.

Getting back to the original question, I guess you're implying there's aren't any interesting functions for constructing arbitraries that I missed? Maybe I should learn how to subclass Arbitrary and see what I can do.

[gruhn]

I guess you're implying there's aren't any interesting functions for constructing arbitraries that I missed?

No, not sure. @dubzzz probably knows best.

The way I'm thinking about this is that in relational terms, combining N independent arbitraries does a cross-product between all of them and then selects one row as the sample, in effect. This is like choosing from select * from A, B. If there's no where clause, it does a cross-product. It would be nice to be able to add constraints similar to a where clause. You could say that a.id == b.parent. Filter can do this, but very inefficiently for equality constraints.

That's a really interesting problem. I've been thinking how to do this without using fc.chain, since that does not work so well with shrinking. I think the main complication comes from the IDs, because they can describe such a complicated web of dependencies. Maybe it's useful to decompose the problem by generating the relations separately from the data.

For example, let's say we have an online shop context and three tables: product, order, customer. A customer can have many orders (many-to-one). A product can appear in many orders and an order can also have many products (many-to-many). For some extra complication, let's say the customer has a name field that must be unique.

The data types and arbitraries could look as follows. The data types have no ID field. Instead we look at an array of records and say that the ID of a record is equal to it's array index. This way we know that all IDs in the range 0 ... array.length-1 are in use. That sacrifices some generality, since the IDs are not completely randomized, but not sure if that's a big problem:

type Customer = {
  name: string // unique
}

type Product = {
  price: number
}

type Order = {
  date: Date
}

function customerArb({ maxLength }): fc.Arbitrary<Customer[]> {
  return fc.uniqueArray(
    fc.record({ name: fc.string() }), 
    { maxLength, size: '+1', selector: row => row.name }
  )
}

function productArb({ maxLength }): fc.Arbitrary<Product[]> {
  return fc.array(
    fc.record({ price: fc.nat() }),
    { maxLength, size: '+1' }
  )
}

function orderArb({ maxLength }): fc.Arbitrary<Order[]> {
  return fc.array(
    fc.record({ date: fc.nat().map(timestamp => new Date(timestamp)) }),
    { maxLength, size: '+1' }
  )
}

Now we can define dedicated arbitraries for generating relations between IDs. That is, they just generate pairs of numbers. That should probably work with any database schema so these arbitraries are very reusable (EDIT: fixed a mistake in manyToOne):

// could use a more efficient representation for many-to-one relations:
type Relation = [number, number][]

// many sources in many targets
function manyToMany({ sourceMax, targetMax }): fc.Arbitrary<Relation> {
  return fc.uniqueArray( // avoid duplicates like: [3,4], [3,4]
    fc.tuple(
      fc.nat({ max: sourceMax }),
      fc.nat({ max: targetMax })
    ),
    { size: '+1' }
  )
}

// many sources for one target
function manyToOne({ sourceMax, targetMax }): fc.Arbitrary<Relation> {
  // Generate an array, where the indices become the source (order) IDs 
  // and the items become the target (customer) IDs. We have to make sure 
  // the array length is exactly `sourceMax`, otherwise we might get orders 
  // without a customer.   
  return fc.array(
    fc.nat({ max: targetMax }), 
    { 
      minLength: sourceMax, 
      maxLength: sourceMax, 
      size: '+1' 
    }
  ).map(targetIds => {
    return targetIds.map((targetId, sourceId) => { // using array index as sourceId
      return [ sourceId, targetId ]
    })
  })
}

Now, we can describe an arbitrary for the full database. Using parameters max, maxLength, etc. we put upper bounds on the size of IDs in use. By tweaking those parameters, we can make it more/less likely that records have a relation with each other. The relations might still contain IDs that don't occur in the associated tables. For example, we might only generate 3 products but the orders_prodcuts relation is free to generate rows with larger IDs. Thus, we need one post processing step where we filter out all the non-existent IDs:

const database = fc.record({
  products: productArb({ maxLength: 20 }),
  orders: orderArb({ maxLength: 20 }),
  customers: customerArb({ maxLength: 20 }),
  orders_customer: manyToOne({ sourceMax: 20, targetMax: 20 }),
  orders_products: manyToMany({ sourceMax: 20, targetMax: 20 }),
}).map(db => {
  const maxProductId = db.products.length - 1
  const maxOrderId = db.orders.length - 1
  const maxCustomerId = db.customers.length - 1

  // The generated relations may contain IDs that don't exist in the
  // associated tables, so we filter those entries out:
  const ordersCustomerAdjusted = db.orders_customer
    .filter(([ order_id, customer_id ]) => {
      return order_id <= maxOrderId && customer_id <= maxCustomerId
    })

  const ordersProductsAdjusted = db.orders_products
    .filter(([ order_id, product_id ]) => {
      return order_id <= maxOrderId && product_id <= maxProductId
    })

  return { 
    ...db, 
    orders_products: ordersProductsAdjusted,
    orders_customer: ordersCustomerAdjusted
  }
})

test('print sample databases', () => {
  for (const db of fc.sample(database, 1)) {
    for (const table of Object.keys(db)) {
      console.log(`### ${table} ###`)
      console.log(db[table])
      console.log()
    }
  }
})

I haven't thoroughly explored the pros and cons of this approach. Just an idea. But I think an advantage is that tables can be generated independently and we don't need fc.chain.

[dubzzz]

The answer provided by @gruhn has the advantage to uncouple the generation of the entities from the one of the relationships without sacrificing shrinking capabilities (no chain nor gen: both helpers have been added to offer a simpler adoption but suffer from unsolvable limitations).

I guess you're implying there's aren't any interesting functions for constructing arbitraries that I missed?

I think no. More precisely so far, I believe I have no built-in provided such level of complexity. That's said the few manyToXxx suggested by @gruhn could possibly be a great starting point to have a fc.schema/database (not planned).