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; } } }

Remove custom super_type from custom object

DavidHaveman

Hello all,

Related to the thread ( https://community.emc.com/thread/138380 ) is there a way to remove the parent custom type of a custom type?

Our object model has

dm_document -> object_a -> object_b

we want to flatten it to be:

dm_document -> object_b

Our existing repository has over 100 million objects that we need to keep in place. The "object_a" in our case has no custom properties at all.

Thanks!

Find more posts tagged with

Comments

Julien.Fontaine

Hi David,

You cannot remove the object_a type without deleting object_b and all your object.

The best approach in my mind is to copy all your object and recreate it in the new type. The problem is that you will lost all the system properties such as object_id, r_creation_date, ...

The second approache is to create new attributes for object_a and do a CHANGE TYPE on your objects !

Good lucks.

DCTM_Guru

Any particular reason that you want to delete object_a type (besides it not being used)? It used to be that table joins were expensive, but this isnt really that much of an issue nowadays.

bacham2

Really? I wasn't aware of that. From my experience, any join you can avoid is a good thing. You should always try to keep your object type hierarchy as lean as possible.

Julien.Fontaine

Yes, are you sure Johnny about that ?

DCTM_Guru

Performance is all relative. My statement is based not only my observation, but others as well on the forums. That being said, one should not design object model 10 levels deep I also agree with bacham that you should design correctly in the first place, but given what David is trying to do, I would examine the pros/cons before trying to do this change if the impact is minimal.

DavidHaveman

The main reason was to clean up the object model, we are also in the process of upgrading and wanted to flatten out the heirarchy. Thanks for your responses. Not sure how far back you mean Johnny, but we are still on 5.3

DCTM_Guru

Julienne recommendations are sound.

If you have access to application source code, then his second approache is to create new attributes for object_a and do a CHANGE TYPE on your objects is straightforward. Obviously, you will need to change the references to your custom code to point to the new attribute names.

Its ulitimately up to you to determine if its worth it.

Julien.Fontaine

With 100 Millions objects, it's quite hard to do a CHANGE TYPE and very long cause for each object, you have to copy metadata and do the change type !!

DCTM_Guru

Yes, do not try to perform a single CHANGE OBJECT DQL for 100M objects. I personally try to limit DQL batch to about 10,000 rows.

Julien.Fontaine

And don't forget to copy metadata from object_b to object_a that can be also time consuming.

DCTM_Guru

For the r_creation_date, r_modify_date, you can run SQL scripts to copy those values to the r_ attributes after your migation is complete.

ldallas

Since ~ 4i the performance tuning guidelines have said that you should avoid inheriting below 4 levels. Because the intermediary object type has no custom attributes the impact to query performance and database size are negligible to non-existent. If you have not already identified a specific technical reason to collapse the model then I believe the risk and time associated with the change outweighs any aesthetic benefit from the exercise.

Or to put it in redneck terms - if it ain't broke - don't fix it.

Julien.Fontaine

Hi David,

Is it ok for you ? What's your final decision ?

DavidHaveman

We're still examining possibilities and upgrade/migration paths.

Thanks for all your input guys!

Julien.Fontaine

You're welcome David !

eikrid

Here is an interesting concept (that needs consideration) and has some restrictions and warning below

Use DQL to change the type of an object. Syntax

change current_type object(s) to new_type where qualification

dm_document

| |

company_doc sop_doc

dept_sop_doc

Restrictions

You cannot make a lateral type change. For example, you cannot change a document’s type from sop_doc to company_doc.

You cannot change more than one level at a time. For example, you cannot change a document’s type from dept_sop_doc to dm_document.

Warning

When you change a type to a parent type, you lose custom property values.

Take care in designing and managing custom types since they are tables of information which may not transport easily to other types.

Julien.Fontaine

Yes, we already talk about the change type but David has some requirement and a basic change type doesn't work for him.