Which field attributes only matter for schema generation?

[ofer-pd]

When I discovered that TextField doesn't currently allow unique=True, it got me thinking... does it matter?

I don't use Tortoise to generate my schema, so there's no point setting field attributes that only matter for schema generation — other than as a form of documentation, which can be accomplished just as well in a comment.

So I did some skimming of the code and confirmed that index does, indeed, only matter for the sake of schema generation.

---

So, the next question is — which field attributes affect Tortoise behavior, and which only matter for schema generation? And might it be useful to describe that in the docs?

After some more skimming, I reached the following conclusions:

• Attributes that affect Tortoise behavior: auto_now, auto_now_add, default, generated, max_length, null, pk
• Attributes that only matter for schema generation: index, on_delete, unique[1]
• Attributes that only matter for schema generation, but are required by the field constructor so you have to specify them anyway: max_digits, decimal_digits

Note: I skipped a few that don't currently matter to me.

---

Would the authors like to comment on this topic, and also, would they appreciate a patch to add something like this to the docs?

---

[1] The exception is if configuring a ForeignKeyField or OneToOneField with to_field attribute pointed at a non-pk field. In that case, you do need to specify unique=True on the target field or Tortoise will complain.

[ofer-pd]

Come to think of it, I guess that question would apply to Meta attributes as well.

For example, if you don't care about schema generation, there's no point configuring:

class MyModel( Model ):
    class Meta:
        index = ...
        unique_together = ...

(Except as a form of documentation.)

[henadzit]

Hey @ofer-pd, thanks for looking into this!

aerich uses some of these attributes for generating the schema. Out of curiosity, what are you using for managing the schema? Aerich has a lot of issues, unfortunately, to the point that I think we need to suggest an alternative to the users.

Would the authors like to comment on this topic, and also, would they appreciate a patch to add something like this to the docs?

We would definitely appreciate a patch!

[ofer-pd]

I currently use a home-made migration system (~250 lines) that supports migrations written in either SQL or Python, and I write migrations by hand. If I want to see the current entire schema, I use a convenience wrapper I created around pg_dump that filters out some of the stuff I don't care about.

I haven't had a chance to look at Aerich yet. I'm very familiar with Django's migration system, and I did briefly use SQLAlchemy's "alembic" system. I've done a little digging around for other alternatives, but it wasn't an exhaustive study. At some point I'd like to continue and complete my research before deciding how to proceed, long-term.

In the meantime, I can create a PR to add the above information to the docs somewhere.