[tx] Accept vector values for :db/cardinality :db.cardinality/many attributes

[ncalexan]

Datomic accepts a shorthand for asserting many assertions with the same [e a] values, where the attribute is :db.cardinality :db.cardinality/many. A transaction of the form

[[:db/add ENTITY :many-attribute [V1 V2 V3]]

is equivalent to

[[:db/add ENTITY :many-attribute V1]
 [:db/add ENTITY :many-attribute V2]
 [:db/add ENTITY :many-attribute V3]]

See http://docs.datomic.com/transactions.html, "Cardinality many transactions". (Note that such shorthand is valid for :db/retract as well as :db/add.)

This ticket tracks rewriting terms with vector values into many terms with scalar values. The relevant code is around 23ea4c9#diff-54794907269c3b2d0bebbfd6a8aeab5dR895.

There are a few wrinkles:

• Vectors could be nested. It stands to reason that [V1 V2 [V3 V4]] would flatten all the way down to [V1 V2 V3 V4] It's almost certainly a mistake in human input, but it's convenient to handles values uniformly in generated input. I have no strong feelings about this and am inclined to flatten vectors entirely. (Lists and sets should be rejected, just for hygiene.) However, this might interact with the next thing...
• Vectors of length 2 can have special meaning: they can be lookup refs (see http://docs.datomic.com/identity.html#lookup-refs). There's going to be some special work needed to disambiguate lookup refs from vectors of length 2 around 23ea4c9#diff-54794907269c3b2d0bebbfd6a8aeab5dR898, and in general it can't be done: if an assertion is

  [:db/add e :many-ref-attribute [a v]]

  where :many-ref-attribute is :db.valueType :db.type/ref and :db/cardinality :db.cardinality/many, and a and v are given as numeric entids or keyword idents, there's no way to distinguish the two cases.

In neither of the situations above do I know what Datomic does or how they try to disambiguate. In the Clojure implementation, I made callers annotate lookup refs like

[:db/add (lookup-ref a v) :other-atttribute v]

to disambiguate. (We could do that here but I'd like to use Rust's stronger type system to not require this manual disambiguation.) For now, let's assume that vectors of length 2 are always lookup refs if they can be and see where that gets us.

This depends on #283, so it's not ready to work on yet.

[rnewman]

I'm inclined to suggest something like: a two-element vector in the value position should be interpreted as two values, and nested lists of items are not allowed.

That allows us to unambiguously equate:

[:db/add e a [x y]]

to

[:db/add e a x]
[:db/add e a y]

and

[:db/add e a [[x y]]]

to

[:db/add e a (lookup-ref x y))]

Thoughts?

[ncalexan]

Thoughts?

I'd be fine with this, although I don't think it agrees with Datomic. Figuring out what Datomic does would be a valuable first step for this ticket.

[ncalexan]

@joe this is a good bug to start with in the transactor.

[joewalker]

Above:

This ticket tracks rewriting terms with vector values into many terms with scalar values. The relevant code is around 23ea4c9#diff-54794907269c3b2d0bebbfd6a8aeab5dR895.

Force pushes rotted the link, are we talking about

mentat/db/src/upsert_resolution.rs

Lines 90 to 125 in 5e3cdd1

	pub fn from<I>(terms: I, schema: &Schema) -> errors::Result<(Generation, Population)> where I: IntoIterator<Item=TermWithTempIds> {
	let mut generation = Generation::default();
	let mut inert = vec![];
	let is_unique = |a: Entid| -> errors::Result<bool> {
	let attribute: &Attribute = schema.require_attribute_for_entid(a)?;
	Ok(attribute.unique_identity)
	};
	for term in terms.into_iter() {
	match term {
	Term::AddOrRetract(op, Err(e), a, Err(v)) => {
	if op == OpType::Add && is_unique(a)? {
	generation.upserts_ev.push(UpsertEV(e, a, v));
	} else {
	generation.allocations.push(Term::AddOrRetract(op, Err(e), a, Err(v)));
	}
	},
	Term::AddOrRetract(op, Err(e), a, Ok(v)) => {
	if op == OpType::Add && is_unique(a)? {
	generation.upserts_e.push(UpsertE(e, a, v));
	} else {
	generation.allocations.push(Term::AddOrRetract(op, Err(e), a, Ok(v)));
	}
	},
	Term::AddOrRetract(op, Ok(e), a, Err(v)) => {
	generation.allocations.push(Term::AddOrRetract(op, Ok(e), a, Err(v)));
	},
	Term::AddOrRetract(op, Ok(e), a, Ok(v)) => {
	inert.push(Term::AddOrRetract(op, Ok(e), a, Ok(v)));
	},
	}
	}
	Ok((generation, inert))
	}

?

[joewalker]

Similar vein:

There's going to be some special work needed to disambiguate lookup refs from vectors of length 2 around 23ea4c9#diff-54794907269c3b2d0bebbfd6a8aeab5dR898,

Except this time I'm feeling lazy - do you have an un-rotted link?