Regarding db_constraint, I think this is a bug

[seejah]

Describe the bug
If the purpose of db_constraint is to avoid generating constraints in the database, then it does not seem to work as intended.

To Reproduce
Create the following data model and run the database migration:

class Feedback(Model):
    id = fields.IntField(primary_key=True)
    user = fields.ForeignKeyField('app.User', related_name='feedbacks', db_constraint=False) 
    title = fields.CharField(default='', max_length=50)

Expected behavior: No foreign key constraint exists in the database.
Actual behavior: Not only does a foreign key constraint get created, it is even more standardized and reliable than when db_constraint=True 😅
My actual requirement is to skip this physical database constraint entirely, while only retaining the relational annotation at the data model layer, with full support for prefetch_related, select_related and values() queries.

[miss85246]

I also run into an issue where db_constraint=False isn't respected during migration. It feels like the migration ecosystem is in a state of disarray—Aerich has been abandoned since Tortoise ORM introduced its own migration tool, but the official solution is not production-ready yet. We're effectively left in a void, caught between an abandoned tool and a deficient one, with no stable path forward for migrations.