[
https://issues.apache.org/jira/browse/ATLAS-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060839#comment-16060839
]
Mandy Chessell commented on ATLAS-1836:
---------------------------------------
Comment from David Radley ([~davidrad]) made on the Wiki page:
david radley
Mandy Chessell . Some comments on Versioned Assets, I am wondering what I am
missing and had some questions:
I see that Versionable is a Referenceable and has a Version Guid, label and
start and end time.
The existing EntityDefs are Referencables and have a Version label. Do we need
to have entityDefs that are not versioned?
I assume the versionGuid refers to a Version artifact that has a Guid. Or is
this guid unique to the entity - if so how is it useful and different from the
existing entity guid? Maybe Verions are top level entities that need to be
governed (controlled and managed consistently according to standard practices).
It seems to me that we would want some sense of order in the versions so there
is a the concept of lower and higher versions. Maybe this as simple as ordering
the String. If there was a Version object - I assume it would handle the order.
Presumably updates could only be made to an entityDef that make the version
higher?
Is there a scope for a particular version?
Currently Atlas does not allow more than one EntityDef to exist with the same
name. Are we suggesting that we could allow multiple active versions?
If an entityDef is moved to a new version, I assume its relationships to
supertypes and other entityDefs need to be copied from the newly cloned vertex
to the historical vertex? We are likely going to need a new label for these
version relationships.
I suggest ActionLogEntry is changed from a structure to an entity. I assume
(probably incorrectly) ActionLogEntry will end up an an entry in a log. If so,
it should have the guid of the entityDef that the action occurred on.
I am not sure what the version status means on the relationship - shouldn't the
status of a version be on the versionable entity itself? Otherwise, if we say
that the status on the relationship is ACTIVE, does this refer to the future or
the previous version?
Why is the previous Version relationship end not on versionable?
In terms of the next steps to get this into Atlas, do we need the
ActionLogEntry at the beginning? Maybe the new version attributes and the
relationship could be added as a first step. If we order based on the version
label string itself, we would ensure that only updates to higher versions occur
and Atlas would create the version relationship when there is an update to
version.
> Area 0 of the open metadata model
> ---------------------------------
>
> Key: ATLAS-1836
> URL: https://issues.apache.org/jira/browse/ATLAS-1836
> Project: Atlas
> Issue Type: Task
> Components: atlas-core
> Reporter: Mandy Chessell
> Assignee: Mandy Chessell
> Labels: OpenMetadata, VirtualDataConnector
>
> This task delivers the JSON files for the new models that describe types for
> Area 0 in the open metadata model. This area covers base types.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
