Project file becomes unreadable after adding ltree type column

[economsoft]

Bug description
pgModeler becomes unable to reopen its own project file after adding a table column that uses the ltree data type together with the ltree extension. After saving the project, reopening fails. Automatic recovery removes the extension and the entire table containing the ltree column.

How to reproduce

1. Create a new model.
2. Add the ltree extension to the database model.
3. Add the ltree data type.
4. Create a table and add a column using the ltree type.
5. Save the project.
6. Close and reopen the project file.
   Result: the project file cannot be opened anymore.

Additional notes on reproduction
When adding the extension and the ltree type is created inside it, the following error appears:
"The extension ltree can't be added to the database model because its child object public.ltree (Type) has conflicting name and type with another object in the model!"
Despite this error, the ltree type appears in the model afterward (!).
If the extension is added first, then the project is closed and reopened, and only afterward the ltree type is added, it is created without error and can be used.
In both scenarios, once a column using the ltree type is added and the project is saved, reopening the file fails.
The only way to recover the project is to manually edit the XML file and remove the column that uses the ltree type.

Expected behavior
The project file should reopen normally after adding the ltree extension and a column using the ltree data type. No recovery process should remove the extension or the table. And, ltree data type should not be added to the model if there was an error message.

Info about your desktop

• OS: Ubuntu Linux
• Version: 24
• pgModeler version: 1.2.2

Additional info
The issue appears to be related specifically to the ltree type when used in a table column. The model file becomes unreadable until the column definition is manually removed from the XML.

[rkhaotix]

Thanks @economsoft

I can confirm the bug. I'll provide the fix for either 1.2.4 and 2.0.0-beta.

A temporary workaround is, if the model fix doesn´t work for you, move the extension definition some lines before the table that uses its type in the .dbm file.

But the fix should have work. It worked for some tests I've during the invastigation for this ticket.