Hi,
I have a reference attribute in a class Which needs to be deleted. All data has-been deleted from the class but when i attempt to delete the attribute, I recieve the following error:
Could not drop classes or attributes of tables or domains containing records.
However, I have deleted all records from the table, when i look in the database, the records are all showing as N and U (not active & updated).
Can I purge These records without deleting the table?
If not, can you suggest a workaround?
Thanks,
Jamie
Hi Jamie,
one of the features of CMDBuild is that it keeps the whole history in the database. Even when you delete a card from a class it is kept in the database. For now it can't be queried from the application but in the future it might (think about an undelete functionality and such). You can't delete attributes from a class, or the class itself, if it contained data because doing so would erase historic data.
The only way you can do this is by going behind the application's back and brutally truncating the tables in the database. It is a delicate operation, and it should never be done in a production environment. Basically you have to truncate the class, its domains, and recursively every class that has a reference over a truncated domain.
Example: i want to delete the A class...
- A has two domains: AB with B and AC with C
- in B there is no reference over AB
- in C there is a reference to A over the AC domain
- C has one domain: CD with D
- D has no reference over CD
With this structure you would start truncating A and its domains AB and AC. Since C has a reference on AC, you would truncate C and its domain CD. There is no reference on CD so you can stop.
Paolo
1 Like
Tecnoteca ha scritto:
Hi Jamie,
one of the features of CMDBuild is that it keeps the whole history in the database. Even when you delete a card from a class it is kept in the database. For now it can't be queried from the application but in the future it might (think about an undelete functionality and such). You can't delete attributes from a class, or the class itself, if it contained data because doing so would erase historic data.
The only way you can do this is by going behind the application's back and brutally truncating the tables in the database. It is a delicate operation, and it should never be done in a production environment. Basically you have to truncate the class, its domains, and recursively every class that has a reference over a truncated domain.
Example: i want to delete the A class...
- A has two domains: AB with B and AC with C
- in B there is no reference over AB
- in C there is a reference to A over the AC domain
- C has one domain: CD with D
- D has no reference over CD
With this structure you would start truncating A and its domains AB and AC. Since C has a reference on AC, you would truncate C and its domain CD. There is no reference on CD so you can stop.
Paolo
Hi Paulo,
I thought as much, thanks for clarifying. What frustrates me is we're in the testing stage, so this is on a test environment. Once the base schema is created, there would be no need to delete these. However, it would be useful in the test stage while implementing suggested ER & class structures.
I have found a way around this though, it involves deleting the reference attribute in the back end and deleting the domains subsequently. This then removes the column without deleting the inactive data. However, using this method I've come across problems with the triggers set as part of the domains which would also require manual deletion.
Like you say, messy, but works for testing and especially helpful in understanding the database structure.
Many Thanks,
Jamie
This is a common issue when initially configuring any EAMS environment.
For example, tonight I was working from a badly formatted technician's worksheet, and added port specific attributes to a network switch chassis. By the time I realized my mistake it was too late.
It seems to me that the limitation should be focused on the column that is being deleted. Other EAMS's with complex object models have no issues safely dropping properties that do not cause system breakage.
Now that I see the shape of the problem, I have a tool that I can configure to do this cleanly using the OpenMaint metadata to navigate the data model. I'll let you know how it pans out.
Previously Jamie wrote:
Tecnoteca ha scritto:
Hi Jamie,
one of the features of CMDBuild is that it keeps the whole history in the database. Even when you delete a card from a class it is kept in the database. For now it can't be queried from the application but in the future it might (think about an undelete functionality and such). You can't delete attributes from a class, or the class itself, if it contained data because doing so would erase historic data.
The only way you can do this is by going behind the application's back and brutally truncating the tables in the database. It is a delicate operation, and it should never be done in a production environment. Basically you have to truncate the class, its domains, and recursively every class that has a reference over a truncated domain.
Example: i want to delete the A class...
- A has two domains: AB with B and AC with C
- in B there is no reference over AB
- in C there is a reference to A over the AC domain
- C has one domain: CD with D
- D has no reference over CD
With this structure you would start truncating A and its domains AB and AC. Since C has a reference on AC, you would truncate C and its domain CD. There is no reference on CD so you can stop.
Paolo
Hi Paulo,
I thought as much, thanks for clarifying. What frustrates me is we're in the testing stage, so this is on a test environment. Once the base schema is created, there would be no need to delete these. However, it would be useful in the test stage while implementing suggested ER & class structures.
I have found a way around this though, it involves deleting the reference attribute in the back end and deleting the domains subsequently. This then removes the column without deleting the inactive data. However, using this method I've come across problems with the triggers set as part of the domains which would also require manual deletion.
Like you say, messy, but works for testing and especially helpful in understanding the database structure.
Many Thanks,
Jamie