[jira] [Commented] (ATLAS-1836) Area 0 of the open metadata model

["Mandy Chessell (JIRA)" <ji...@apache.org>]

    [ 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)