storing (meta)data ?

[Danny F]

Hi

If I would want to store additional information on an element which I want in no way to be available in the EA User interface, how could I do that ?

As an example :
If I want to store the fact that an element is created by my add-in (as opposed to created by the user via the interface)

Thanks in advance for any advise

gr

[g.makulik]

I'm currently working on the same problem. Maybe Geerts solution from this thread already helps for your purposes.

HTH
Günther

[Ian Mitchell]

Assuming that you don't want it to be a simple TaggedValue (which WOULD be visible in UI) then I guess all you can do is to use one of the existing columns in t_object. This would be dangerous, as Sparx might overwrite your data from somewhere else in the UI.
One approach might be to create a property of the element (in t_objectProperties) and put your data in there? Best to wait for the definitive solution from QUERTY...

[qwerty]

Paolo once asked that question. What came up from this discussion was to create a private table. A good idea would be to call it p_<purpose>. The p_ for private would hopefully guarantee that Sparx will not create an own table with that name since they prefix all of them with t_. It would be nice if EA somehow would support handling of such tables so you would not need to use Repository.Exceute but some intrinsic function.

A private table means extra effort in creating databases. Also the export to XMI would not export everything. Somehow you would need to write a special export reference data. Further the Project Transfer would not transport the private table so you need to do that manually. But the risk of misusing EA owned columns is to dangerous.

What just comes to my mind is to create entries in t_xref. Since the primary key here is a GUID you're absolutely save in terms of transferring a model. Of course, if you transfer data via XMI you'd need to care for your entries in an extra export.

However, the preferred way is to use tagged values

q.

[stao]

i would highly recommend to use taggedvalues to store your data.
you can use the "notes" field to story a big amount of data.

here is the link to a framework which can be used to store data as a "tree" structure as xml in the notes field of a taggedvalue.
 create a tree and the framework will do the rest

 -> xml -> text -> taggedvalue notes

http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1351857035/0#0

[Danny F]

Thanks guys for the responses
I think I'm not going to misuse existing EA columns  
maybe t-xref is an option.....

for now I'm going with Stao's solution - 1 TaggedValue notes field
Thanks a million Stao

[Geert Bellekens]

Thanks guys for the responses
I think I'm not going to misuse existing EA columns  
maybe t-xref is an option.....

for now I'm going with Stao's solution - 1 TaggedValue notes field
Thanks a million Stao

That's probably what I would do as well.
If you really want to you can also prevent the user from changing or deleting the tagged value in your add-in.

Geert

[Danny F]

Thanks Geert

And yes - I really want that - bad enough they will be able to see it