nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Cannot find information about ‘extended properties’ (a_extended_properties)

GlenLantz

1. In document Documentum_System_66_Object_Reference.pdf I see dm_sysobject having property a_extended_properties.

But I cannot find more info about usage of the a_extended_properties in the docs I have (Documentum_System_66_Object_Reference.pdf, Documentum_Foundation_Classes_66__Development_Guide.pdf, Documentum_Content_Server_66_DQL_Reference.pdf etc)

2. I am considering the a_extended_properties because of I have to add a non-standard property (‘custom property’, ‘user-defined property’ – it may be named in different ways) to dm_document objects. I do not want (be some reasons) to use ‘aspects’. So the ‘property bag’ seems more suitable for this. But I also see the a_extended_properties that sounds suitable for this too; but see not details about its usage.

Documentum experts, please advise – is there sense in usage of a_extended_properties for this my need; or ‘property bag’ is quite enough?

Find more posts tagged with

Comments

DCTM_Guru

"...I cannot find more info about usage of the a_extended_properties in the docs I have (Documentum_System_66_Object_Reference.pdf"

Really, I just found this info in the Object Reference manual:

"Values of the relation_name property in a dm_relation object or subtype of a dm_relation. This is used in conjunction with the r_object_id of the sysobject to
identify the relation object that contains the SysObject’s extended properties."

Its best practice to create your own subtype of dm_document and add your custom attribute there. If you are not able to do this, then I suggest you use some other system attribute that is not reserved by Content Server (eg title, subject).

GlenLantz

1. "Really, I just found this info in the Object Reference manual" - yes; but nothing more excepth this. It is not clear for mr from that excerpt - how do I add an 'extended property' to dm_document; this is my problem.

2."then I suggest you use some other system attribute that is not reserved by Content Server (eg title, subject)." - yes, I though about this. But what about the 'property bag' - can it be used for this? What are its advantages/disadvantages?

DCTM_Guru

1. You should not extend dm_document (or any system object) type. You should create your own custom type derived from dm_document. Any changes to system type may get overridden if you upgrade and all your data may get loss.

2. As you originally stated, property bad is designed to be used with aspects. If you dont want to use aspects, then dont mess with attributes that design to support it. You may end up with behavior that is different from what is expected and as soon as you open a support ticket with EMC, they will tell you that you should have used this attribute this way and will not support you.

GlenLantz

“Any changes to system type may get overridden if you upgrade” – you mean software upgrade? For example, upgrade of Documentum 6.5 to 6.6 etc

“You should not extend dm_document”: yes, this would be great - if I was a person who owns the Documentum Content Server instance and had ability to do this. But in my case the task is: I am given a Documentum Content Server instance, and I have to find a way to synchronize already existing documents of its folder with folder of other document-management system.

Trying to do this I have come to the conclusion: I need to store somewhere in dm_document an another property that will be a ‘foreign key’ to the ‘other document-management system’. It will be ID of document in the ‘other document-management system’ that corresponds to this dm_document object. This is why I am looking for a ‘field’ where I can store this ‘foreign key’ (string up to 50 symbols).

Having this description of my task – how do you think, what would be better solution?

Thanks in advance

DCTM_Guru

“Any changes to system type may get overridden if you upgrade” – you mean software upgrade? For example, upgrade of Documentum 6.5 to 6.6 etc

- Yes. EMC may decide to change the definition of system objects during upgrade. If you create your own custom type, your custom type will not be affected.

- Hence, my suggestion on using system attributes like title or subject. Both of these fields have char lengths > 50.

GlenLantz

'Hence, my suggestion on using system attributes like title or subject. Both of these fields have char lengths > 50'

yes, I thought about this; probably I will use it. But before I would like to get known - how this problem can be decided by real Documentum gurus; this is why I had asked :-)

DCTM_Guru

Its always good to ask for other people's opinion on design. I still do design reviews with my colleagues even though I have been working with Documentum for 15 yrs

GlenLantz

So: can someone else give me more advice(s)?

lastnitescurry

Based on your recent posts (about tbos, aspects, external tables, replciated content,...) my advice would be:

Go back to your customer and explain to them that having dm_document as the type for your content is plain crazy. Explain that custom subtype of dm_document is how Documentum is extended. Has been that way for years and not likely to change.

If they do not wish to authorise a custom subtype, then suggest it will take about 10 years to immplment what ever the heck they want.

If they do authorise a custom subtype, then you can get a solution working quickly, add your custom attributes and one for sync state which is managed by a TBO.

GlenLantz

Thank you.

and what about the 'property bags' - cannot they help me?

DCTM_Guru

Property bags is designed to be used with aspects. If you dont want to use aspects, then you shouldnt try overriding their behavior, b/c you may end up corrupting the repository or at the very least, have unintended behavior out of the native Documentum applications.

GlenLantz

Thank you; this is what I wanted to hear,.

To everybody : maybe someone has objections about this property bags constraint?

agoodale

Actually, property bags are not designed to be used with aspects. They are indeed useful with aspect types, but in fact, they are simply a means to store properties without the overhead of a separate SQL column. Attributes in the property bag behave like normal attributes, with all data dictionary information.

To use property bag attributes, you still need a custom subtype of dm_document. I would recommend using them only if you are sure you never need to use the attributes in a DQL predicate, and you don't want the overhead of SQL columns for the values.

Extended properties means using a dm_relation subtype to store custom metadata. This technique works like aspects, in that a completely separate table is used to store the metadata, but you'll have to manage how the metadata behaves when an object is copied or versioned.

GlenLantz

Thank you for the answer - now these things become more clear for me, although not yet completely :-)

'To use property bag attributes, you still need a custom subtype of dm_document' - and there is no way to use property bag without creating subtype of dm_document? I am asking this because of my task is the following: I have to find a way to put into Documentum's document an 'external ID' - string that links the document to corresponding document of another documant management sytem. My customer already has a lot of documents as dm_document objects; so I have to work with them, not with dm_document subtypes. This is why I need to somehow put an 'extra atrribute' into existing dm_document objects.

DCTM_Guru

"...already has a lot of documents as dm_document objects;"

- You can easily change the object type (from dm_document to custom subtype of dm_document) by using CHANGE DQL statement.

agoodale

If the objects and types already exist, I think your best option is using a dm_relation subtype and the "extended properties" design pattern. Attaching the relation to the documents will not require modifying them in any way (no r_modify_date change). I wouldn't necessarily even set a value in "a_extended_properties" unless you feel the need, or it makes distinguishing the objects easier in some way.

This is the kind of thing aspects were designed for (adding metadata/behavior to objects across different types), but since you can't use them, a relation is your only other option, AFAIK.