Support interned keywords

[rnewman]

:db/valueType :db.type/keyword is used to denote a restricted set of values. But we store these as strings. We should consider a schema flag to signal that a keyword value should be automatically interned (as an ident or otherwise) to avoid storing duplicate strings in the database.

[rnewman]

Note that Datomic does intern keywords.

[ncalexan]

This is interesting, because it's identical to using a :db/ref type to a :db/idented entid. The set of known idents is kept in memory and should be very small; I think it would be okay to only accept keywords that already have an ident associated, so that keywords are really enums. This could be loosened in the future by automatically generating idents for keyword values (at the cost of generating datoms the user didn't explicitly specify), or by storing the intern map separately from the datom store, or by fixing the intern mapping globally.

[rnewman]

Circling back to this: it's not quite identical to using :db/ref:

• :db.type/keyword doesn't require a namespaced keyword; idents do.

• You can't :db/ref to an undefined ident, so you would need to pre-process identifiers (or do it automatically, as you say). I suspect those need to be transacted in an earlier transaction so that the schema is updated, too.

• The user would likely be surprised that all of their keywords have to be, or automatically are, included in the ident map.

• Refs aren't automatically keywordized on the way out; keywords would be.

• More crucially, keywords are a subset of the value space, and idents are a vector into the entity space. This is not a result-returning query:

  [:find ?x :where [?a :foo/akeyword ?v] [(= ?v :thing)] [?v _ ?x]]

  because ?v cannot simultaneously unify with a TypedValue::Keyword and an entity.

That said, I don't see much wrong with reusing chunks of the ident-interning mechanism to automatically intern keywords — but it's something that only the transactor and the query engine will see.

[rnewman]

Additionally: I don't think it necessarily makes sense for this to be a property of an attribute, and we should think about doing this automatically for all keywords… or, conversely, making this an option for all large types (URIs, bigints, strings, keywords).

The nice thing about associating this with a type, rather than an attribute, is that we avoid the kind of split we have with fulltext strings.