Preserve identity of records and other structural values

[sanjiva]

Suppose I have:

type Class record { string name; }
type Student record { Class class; int name; }

And assume that multiple Student records values refer the same Class. (I need to model it this way because I can't create the whole class at once - I create it and then add students to it. (See https://github.com/sanjiva/Staffing/blob/master/src/services/types.bal for a real example.)

The above record can't be json'ed as-is.

We need some way to represent references across records in a network transportable way.

[sanjiva]

Note that this is similar to what is needed to persist such a structure into a relational system. JPA etc. address this issue with various kinds of relationship annotations. For example, see: https://www.javatpoint.com/jpa-creating-an-entity.

[jclark]

More precisely, if you convert that structure to a string in JSON format and then parse that string back into a structure, your graph structure will have been turned into tree: the identity (===-ness) of the class values has not been preserved.

[jclark]

This relates to #338. We do not want to preserve the identity of all records: only those that represent "entities". For example, in the linked example Date is not an entity. But the language does not have a built-in way of distinguishing the records which have an identity. You have to do it yourself by e.g. putting in a uuid field.

[jclark]

This also relates to #354. One big issue is primary keys, which are in effect a mechanism to give records an identity within a particular context.

[jclark]

This also relates to #159, since BVN should provide a way to maintain graph structure of anydata.

[jclark]

We can provide a layer on top of JSON to allow graph structure to be preserved by using:

• JSON pointer
• $ref from JSON schema

[jclark]

YAML's data model is a graph, so that might be another way to allow graph structure to be preserved.

[jclark]

We should look at JDO and also at ODMG ODL (which JDO developed from). I think we may well need something like the extent concept.

[sanjiva]

I think the key comment you've made is the one about entities vs. records. Not all records are entities, that is, records which need to have identity on their own right (which is what #338) is about.

Once we can distinguish between them we need to address how to map entities to JSON / YAML / SQL Tables etc..