Using SQL to filter out elements superseded by the Clone Element Feature

[Phil.S]

I was very happy to see the new "Time Aware Modelling" feature that was introduced in Version 13. Within my organisation we frequently use custom queries written in SQL to filter elements prior to RTF reporting. One query I have is how can we efficiently and accurately identify the superseded versions of an element using SQL, and therefore exclude them from the query results?

I have looked at how the versions of a given element are linked and having looked at the entries within the t_connector table the Connector Type used is "Abstraction", which means that if you filtered for elements linked to a given element via the "Abstraction" connector you could not rule out including elements that had been linked manually as an Abstraction (as opposed to linked automatically by the clone facility).  Within the t_connector table I have compared an entry for a manually created Abstraction connection against one created automatically by the clone feature. The only discernible difference between the two is that any records created by the clone tool seem to have the StyleEx field populated. In such cases the StyleEx field contains an entry like "version=1.1;VOF=1;. It appears the version part of the entry refers to the cloned version, which is great, but I am unsure what the VOF part is referring to. At the moment I don't know if this type of entry is exclusively used by the clone feature and therefore I am reluctant to use it as the basis of an SQL query to filter out the superseded version of elements.

What would be really great is if there was a flag against an element to mark it as being the most recent version. I know I could create a custom tag but that would mean manual management and ideally the clone feature would automatically mark an element as the most recent version when it is automatically created (whilst at the same time removing the flag against the now supersede element).

I'd be interested to know if anyone else has considered this issue and also whether there does exist an easy (or at least foolproof) way of excluding the superseded versions of elements from a SQL results set.

Many thanks

Phil

[KP]

Every Abstraction that was created by the cloning mechanism will have 'VOF=1;' in its t_connector.StyleEx field. Not sure what VOF stands for - probably 'version of' - but the '1' means 'true', so read it as saying 'the client is a cloned version of the supplier'. To find the most recent version of an element, you will need to recurse along the chain of Abstractions. I don't think it can be done with a single SQL query.

[KP]

and also whether there does exist an easy (or at least foolproof) way of excluding the superseded versions of elements from a SQL results set.

An element has been superceded if it is at the supplier (target) end of any Abstraction which has 'VOF=1;' in its StyleEx field.

[Paolo F Cantoni]

Clones are NOT abstractions...  They are Clones.  To be an abstraction, you need to be at a lower level of detail.

Because the Trace semantics are a form of abstraction, they are probably inappropriate for the cloning mechanism.

Cloning is actually a form of transformation.  In our cloning mechanism, we created the explicit semantics "ViewOf"(a form of dependency) to describe the relationship between the clonee and the cloned.  Perhaps, THAT's what VOF stands for.  (As an aside, I find it "passing strange" that Sparxians aren't able to say definitively what things mean on planet Sparx.  Is the code created in a different universe and you Sparxians are merely high priests trying to make sense of the arcane?   Give us users a break and find out what VOF actually means and let us know.)

We're still evaluating the cloning mechanism provided in V13, but it looks like it offers promise.

BTW, we also use the "ViewOf" to link our local models to "Reference Models" provided from external sources.

HTH,
Paolo

[KP]

Give us users a break and find out what VOF actually means and let us know.

I have said exactly what 'VOF' means, you are welcome to decide what the individual letters stand for.

HTH,

In a discussion about the detail of how things are represented in the database, opinions on how it could have been done better probably aren't helpful, no.