Unique property of field appears unchecked though the database change was successfully applied

======== TEMPLATE BUG FORM ========

Wappler Version : 6.8.0
Operating System : Windows 10
Server Model: NodeJS
Database Type: MariaDB
Hosting Type: Localhost + Docker for DB

Expected behavior

When setting a field as unique, it should also appear that the checkbox for the unique property is marked.

Actual behavior

When I add the "unqiue" attribute to one of my fields and apply this change to the database, the checkmark disappears in the "PROPERTIES" section, after refreshing the full schema.
Still. The database change was successfully applied.

How to reproduce

First step: Create a new table with an increments and uuid key.
(Another bug: When creating the UUID field, upon first creation the "primary" checkbox appears unchecked. After clicking on something else and back onto the UUID field, it is being displayed as checked. This bug was already referenced here: Error when creating field type UUID (not as primary key) on the 25th of june and here Bug in UUID Reference Handling Between Tables in Wappler - #5 by Hyperbytes)
MAKE SURE TO UNCHECK THE PRIMARY BOX AFTER CLICKING ONTO THE UUID FIELD AGAIN OR ELSE YOU CANNOT MAKE SURE TO CREATE THE TABLE WITHOUT PROBLEMS!
Second step: Apply database changes
Third step: When now clicking onto the uuid key and making it "unique", after applying the database change, the uuid key is indeed unique.
After refreshing the full schema or just the schema of the table the checkbox appears as unchecked though the database change was successfully applied and the field is indeed being handled as "unique".
If one tries to set it unique this time and apply the dbchange, it states "Error: alter table userdb add unique userdb_uid_unique(uid) - Duplicate key name 'userdb_uid_unique'.

Another remark:

After trying to create another table, it is not possible to set the unique uuid field as a reference for a reference field in a new table.
The following error is given:
Error: alter table test4 add constraint test4_testuidref_foreign foreignkey (testuidref) references userdb (uid) - Can't create table db.test4 (errno: 150 "Foreign key constraint is incorrectly formed").

After reloading the scheme due to this error message (which can sometimes result in a crash of the whole database manager, where I have to restart wappler due to seeing nothing anymore besides a black wall in the database manager), the reference field somehow transitioned into a integer field with no sign of a reference field besides maybe the icon still being an arrow.

WARNING: If the DBManager crashes and you restart wappler, you have to refresh the schema or else it will appear to have successfully created a reference field! After refreshing the integer field apperas instead of the reference field.

This is the knex code:


exports.up = function(knex) {
  return knex.schema
    .table('test4', async function (table) {
      table.integer('testuidref').unsigned();
      table.foreign('testuidref').references('uid').inTable('userdb');
    })

};

exports.down = function(knex) {
  return knex.schema
    .table('test4', async function (table) {
      table.dropForeign('testuidref');
      table.dropColumn('testuidref');
    })
};

The database manager somehow appears to try create an integer, though a uuid field is being referenced and set in the properties beforehand.

last remark:

If I really want to create a ref field for a uuid field, I have to first create a random string field in the new table, then undo the change.

And after this, I inserted this into the migration file:


exports.up = function (knex) {
  return knex.schema
    .table('reftable', async function (table) {
      table.uuid('refuid');
      table.foreign('refuid').references('uid').inTable('userdb');
    })

};

exports.down = function (knex) {
  return knex.schema
    .table('reftable', async function (table) {
      table.dropForeign('refuid');
      table.dropColumn('refuid');
    })
};

Then I only have to apply the change from the changelogs again.

Addendum:

The reference field, independently of referring to a uuid or any other type of field, always tries to form a integer, though the referenced field is a uuid field or even a string field.