repeating property as of a custom object type

I have a question on repeating property. Let's say I define a repeating property "reviewers". However, each of the value for reviewers is not a literal string. Instead, it consists of reviewer name, email, and phone number. So it is really repeating the construct and group. Can I create a custom object type, say "my_reviewer" for (reviewer name, email, phone number) and make "reviewers" a repeating property of this type? Or does Documentum only accept built-in data types (Boolean, String etc) for properties? If this doesn't work, how could we handle this requirement then? Each individual piece of data needs to be searchable and retrievable, though. Thanks in advance.

Find more posts tagged with

Comments

shailshah

You can create a new custom type called my_reviewers, create object instances (contentless, i assume) of these types and save their r_object_ids as a repeating attribute value (reviewers) on your custom type. You will be responsible for managing instances of my_reviewer type and assign/unassign them to the repeating attribute. This can be done as a TBO or customizations depending on the nature of your application. Aspects is another option - but I have not used them beofre so cannot comment.

You can also use dm_relation objects to associate a content object to reviewers. The design will depend on your requirements and how exactly this information will be consumed.

I am not aware of any out of the box support.

Thanks for the helpful response. I have not used TBO before so I will look into it.

If I create "my_reviewer" type and search for reviewer name, will the search result bring up "my_reviewer" objects instead of "my_document" objects? I am trying to make this transparent to end users - they don't need to know "my_reviewer". Everything should appear to be part of "my_document" to them. Is this possible?

In a broad sense, I guess my question is how to model "has-a" relationship. Documentum said it is object-oriented. In OO, there are "is-a" relationship and "has-a" relationship. Documentum's inherirence/supertype/subtype handles the "is-a" relationship well. In case of A has B, it is also fine if B is a built-in data type - B is simply a property. But what if B itself is a custom object type? To make it more interesting, what if B is also repeating, i.e., A has a list of B?

The real use case I have is actually like this:

A has a list of B AND a list of C. B and C have their own properties.
Only A has content
The properties of B and C must be searchable but the search result should bring back A

TIA.

I think I found the answer - Aspect, part of BOF since release 6.0. Aspect can be used to extend behavior and/or attrbiutes. In case of "A has a list of B and a list of C", I could create aspect B and C with their correspoinding attributes then associate them with object type A as repeating aspects. I haven't tried it but it seems to be exactly what I am looing for.

It turns out that an aspect can have repeating attributes, but the aspect itself cannot be attached as repeated. In that sense, it can handle "A has B" but not "A has a list of B". Documentum claims to have an object-relation model. O/R mapping tools, such as Hibernate, can handle this Collection mapping naturally. I wonder if and how Documentum does that.

gcampos

Creating another type with its own attributes as already stated is the best option, we do this every time we need such approach.

When you link objects using IDs, the search is done using the ID number, but you can bypass this behaviour with a custom search class for this attribute, acting like a Value Assistance.

Locate the advsearchex.xml in /wdk/config folder and copy it to /custom/config, this is a special XML and you can't use the "modifies/insert/append" or the "hierarchy" concepts used commonly in wdk components.

Modify the copied file adding the attribute name and the class that will handle the search i.e.:

<contacts>com.mypackage.advsearchex.tags.ContatNameVATag</contacts>

your class should extends ExistingValueVATag or a related class.

And you will have a method like this one:

protected void populateValueDropDownList(SearchDropDownList searchdropdownlist) {

        setSelectFromType("my_custom_contacts_type");
        setValueAttributeName("r_object_id");
        setDescriptionAttributeName("contact_name");
        super.populateValueDropDownList(searchdropdownlist);
    }

In my example, the primary type holds the object_ids of my_custom_contacts_type objetcs in a attribute called contacts, and the search will be done in the attribute contact_name of the type my_custom_contacts_type.

I think you can find more about this on Search Development Guide, a PDF available in powerlink.

"Creating another type with its own attributes as already stated is the best option, we do this every time we need such approach." With this approach, I assume there is no built-int mechanism to enforce the referential integrity (this is like a foreign-key in relational database). That's why the previous post said "the application is responsible to manage it". Am I right?

In addition, the "Value Assistance" is very interesting. But is it only applicable to WDK? I am programming DFC.

DCTM_Guru

Value assistance is defined in the data dictionary (at content server level). Its up to the client (eg Webtop) to look up/enforce what is defined in the data dictionary. So if you writing your own DFC app, you will have to query for the correct values defined in the value assistance in the data dictionary.

gcampos

When I said about the approach I was thinking in the way we store the data (using two types), but I must say that we don't needed integrity between the objects, so we haven't used relations yet. In the other side, I know that WebPublisher uses dm_relation to keep integrity between the web content and its attachments or images.

You can try using a dm_relation between the objects, dm_relation has a relation_type attribute that is the name of the dm_relation_type object that defines the relationship between the parent and child. The dm_relation_type defines the name, behaviour (when copying, deleting, etc.) and security (create relation, drop, etc.) for a relation.

I don't know if the behaviour (cascade delete, referential integrity) is enforced by content server, maybe you should evaluate that.

The idea:

- Create a new "Type of Relationship" (dm_relation_type) that describes security and integrity for your kind of relation

- For each parent-child relation, create a dm_relation object linking both and using your relation type, maybe you can work directly with the relations, without the need to store the child object_id on the parent object.

I found a lot of information on "Object Reference 6.5" PDF, that is available in EMC² Powerlink.

About the Value Assistance, yes it is WDK programming (but note that I talked about WDK Search customization, not DAB/Composer/Type value assistance), as you asked about searching I thought that you were using Webtop Search or another WDK client.

But if you are developing your own DFC app you must take care of that. Maybe there can be a way to recover the value assistance recorded in the Data Dictionary info, but that's not the case, as your objects are always changing (i.e. new child objects are being created) and your value assistance would be query dependant.

Hope that helps.

Message was edited by: Gustavo Campos

Thanks for the quick response.

I read a little on relation and it indeed can enforce the integrity and also cascade-delete between parent and child. It solves part of my problem. Howerer it is still unclear how search works in this case. For example, if there is a match on "contact_name" in child, I suspect the search result will bring back the child object, instead of the parent object. It makes sense since child is a standalone object independent of parent. But what we need is to make child an integral part of parent so end users only see parent objects. Is there a way for search to bring back parent even though the match happens in child? The same question can be asked to the "two types" approach.

Aspects, on the other hand, handles my search requirements well. The search resul will always bring back the type object, even though the match is on the aspect. I guess that is because an aspect is considered an entension of the type it is attached to. it is like implementing Java interfaces. But as I said in previous posts, I am stuck with the "repeating aspect" part.

Thanks again.

gcampos

I think I didn't understood yet how you will do the search.

Are you using Webtop or any WDK based application? Or a custom app that use WDK components? How the search is done? Do you have the Full Text Index Server?

As I said, everything is DFC programming. There is no UI, either WDK or Weptop, involved in this part. The APIs will be exposed as web services. And yes, there is full-text indexing.

gcampos

So, you will have to write in your API something to handle the search, i.e: if the type searched is X and the field searched is Y do some custom logic to handle the separate storages.

Using TBO or Aspect you could create a custom method that always return the necessary fiels when called, the method could take a String as parameter, and return the entire line with the information, or even a structure like Map, Set, Array, etc.

But I think there is no way to change the DQL behaviour (if you are thinking to use it as the search method) to use some kind of value assistance.

If you are providing a web service to the search and the web service just executes a DQL/SQL, without any other custom logic, you could change your primaty type views (_sp and _rp) to join into the secondary type and bring the data instead of the child ID, that way you can write a WHERE clause filtering by the secondary type fields.