v15.2 - Time Aware Modelling - Clone() method is that the correct one?

[Paolo F Cantoni]

If we wanted to use the TimeAware Modelling cloning functions, is the Element.Clone() and Package.Clone() methods the correct one to call to achieve that?
[Edit: some forum searching has revealed that this is, indeed, the case.]

The documentation doesn't supply any description of the functionality, so should we assume that we have to do all the "leg work" ourselves following the return of the new clone item?

[Edit: any gotchas from those who have "used it in anger"?]

TIA,
Paolo

[Eve]

They are not related to time aware modeling.

Element.Clone() appears to have been added 4 years before time aware modeling and just duplicates a single element.

Package.Clone() appears to have been added 9 years before time aware modeling and it duplicates an entire package.

[Paolo F Cantoni]

They are not related to time aware modeling.

Element.Clone() appears to have been added 4 years before time aware modelling and just duplicates a single element.

Package.Clone() appears to have been added 9 years before time aware modelling and it duplicates an entire package.

OK, Eve, so how CAN I call time aware modelling from the API?  The Clone() function did seem to be missing some functionality for the Time Aware Modelling process.

Paolo

[Ian Mitchell]

This is a really useful API method.
It copies not just the fields of one element to the clone, but also attribute and methods, internal structure like Requirements and Constraints, as well as tagged values. It doesn't copy child diagrams or child elements - which is sensible, or connectors, which is very sensible.
@Sparx - perhaps the documentation might be updated to reflect the scope of the operation ?

[Geert Bellekens]

This is a really useful API method.
It copies not just the fields of one element to the clone, but also attribute and methods, internal structure like Requirements and Constraints, as well as tagged values. It doesn't copy child diagrams or child elements - which is sensible, or connectors, which is very sensible.
@Sparx - perhaps the documentation might be updated to reflect the scope of the operation ?

Downside is that it creates that clone in the original package. And if that original package is locked, or under version control, that causes issues.

We needed to clone elements without checking out the original packages, so our workaround was:

- update the database directly to change the packageID of the element we want to clone to our working package
- clone the element
- update the database directly to change the packageID back to the original package

I would be nicer if we could pass a packageID to the Clone() operation to act as it's new owner; that would avoid all the nastiness

Geert

[Paolo F Cantoni]

This is a really useful API method.
It copies not just the fields of one element to the clone, but also attribute and methods, internal structure like Requirements and Constraints, as well as tagged values. It doesn't copy child diagrams or child elements - which is sensible, or connectors, which is very sensible.
@Sparx - perhaps the documentation might be updated to reflect the scope of the operation ?

Downside is that it creates that clone in the original package. And if that original package is locked, or under version control, that causes issues.

We needed to clone elements without checking out the original packages, so our workaround was:

- update the database directly to change the packageID of the element we want to clone to our working package
- clone the element
- update the database directly to change the packageID back to the original package

I would be nicer if we could pass a packageID to the Clone() operation to act as it's new owner; that would avoid all the nastiness

Geert

Shoot that man!  He's making sense!


Paolo

[Ian Mitchell]

Arghhh - I just found the same issue - clone doesn't work at all if the source is locked: just returns 'nothing'.
This seems like a bug? The source is read-only, and 'clone' is just reading it.
Geerts's approach seems to be simpler.
@Sparx - do you think this is a bug?

[Ian Mitchell]

There are a few other funnies with this approach.
Or maybe it's my lack of a deep understanding of the internals of locking.
If I use Geerts approach - which, like Geert, is mostly perfect -  EA seems to be sensitive to the locking which is applied in the target package.

- If the target package (where I want my clone to go) is locked, but un-locked to the current user
AND
- has no parent packages which are unavailable to the current user, then all is well.
For example: (extra brackets so the colors are more visible.)

(!) Package 1
--- (!) - my target package
- everything OK

BUT for:
(!) Package 1
---((!) - my targetPackage
...then the element.clone fails - even when I use Geerts 'package switch' SQL, and I'm putting the clone into 'my target package'.

So it seems to be sensitive to the locking of the parent of the target package.
As you can imagine, this has taken a while to debug.
Does anyone have any ideas why this might be true? Hard to go any deeper, as it's all hidden inside of the 'clone' function...
...which is SO useful, I'm prepared to go to some trouble to use it, but I'm having doubts. Saying 'you can use this, but only if your locking scheme works exactly like this..." doesn't seem friendly.