Open ComLock opened 5 years ago
This is a "no go", at least for the _id field. Simple reason, you should be able to export and import nodes across repos.
A bit of a misunderstanding here; I think we want to make the repoId available in the index for e.g aggregations
@sigdestad @runarmyklebust
Once you think of a repo as a database rather than a table: cross repo id's does not make sense.
But then multirepoconnection query (including aggregation) also seems a bit abstract. Because a multi database query does not make sense.
I guess it's because my mind is so used to databases that I'm stuck in a paradigm.
In a PostgreSQL db the oid is typically not something the developer knows or cares about. But we have made our internal id very visible. In a database world one would make our own primary keys with a uniqness constraint (and use that in joins). If a Enonic XP developer is going to stop caring about the _id field, and create own "primary" keys, there needs to be a standard way to make and enforce uniqness.
The challenge of uniqueness is something I come across quite often. In javascript an object key is unique. To reproduce such uniqueness in Enonic XP schemas so they can map nicely to Javascript objects is not possible.
The proper solution to https://github.com/enonic/xp/issues/6757 is to make a uuid in the index that is unique across repos. Such an uuid would contain both the repo-id and the node-id.