CMDBuild Forum

Feature Request: Database Cleaning and Id attribute using UUID

Dear Technoteca,

 

Yes this is features request:

 

I have been using CMDBuild for 1 year now. I have been running the same instance that I started last year. Starting from version 2.0.1, I have upgraded to the latest version progressively and now I am using Version 2.1.5. I have been monitoring the Database and I notice the most common class is bloated with plenty of stale information which I know for fact that would never be use ever again. I cannot say for sure if it degrade CMDBuild speed or not but it would be nice if there is a function to sanitize the database.

 

I know Integer in PSQL is a very large number but I have been facing some difficulties with integer values right now. Has any body consider using UUID for the Id attribute?

 

Regards,

Zahri 

Hello,

I suppose you are referring to the updated versions of the CMDBuild cards (history cards).
CMDBuild philosophy is to track all the changes to all the cards, maintaining their complete history with the change date and the change author.
For this reason it is not possible to delete that data from the database.
This mechanism has not, however, relevant impacts on the database performances.

Regarding the integer fields, they
can hold values ​​up to 2147483647, which we believe are sufficient for the number of objects managed in an asset management system (including history).

CMDBuild Team

 

Noted on the comment.. I will find other alternative ways to solve my own problem.. Thanks.
 
Previously Tecnoteca wrote:

Hello,

I suppose you are referring to the updated versions of the CMDBuild cards (history cards).
CMDBuild philosophy is to track all the changes to all the cards, maintaining their complete history with the change date and the change author.
For this reason it is not possible to delete that data from the database.
This mechanism has not, however, relevant impacts on the database performances.

Regarding the integer fields, they
can hold values ​​up to 2147483647, which we believe are sufficient for the number of objects managed in an asset management system (including history).

CMDBuild Team