search

tortoise / tortoise-orm

Familiar asyncio ORM for python, built with relations in mind
https://tortoise.github.io
Apache License 2.0
4.66k stars 389 forks source link

Ability to disable backward relation #262

Open wallneradam opened 4 years ago

wallneradam commented 4 years ago

Is your feature request related to a problem? Please describe. I think a lot of times you just don't need the backward relation, which is now automatically created by Tortoise. It can be a problem, when you have multiple interpretation for the same model. E.g. a user can be referenced multiple times, but never want to use it backwards.

Describe the solution you'd like I have 2 solution proposals. Either or both would be good.

  1. You can give related_name parameter as False or empty string (I prefer False): 
    user: fields.OneToOneRelation['User'] = fields.OneToOneField('models.User', related_name=False, null=True)
  2. Only you use the backward relation if you specify it in the other side with annotation. In modern Python it would be a good solution. Without it IDEs can't know that property exists.

Additional context I have this problem in my PR #260 . If you don't agree with this request, I still need to know somehow from backward_*_fields, which field has annotation at the other end. It could be described in a new property called e.g. annotated.

grigi commented 4 years ago

Hmm, option 1 is backwards compatible, and option 2, whilst clean (specify if you want it, else don't bother) could break existing code. Which will let me rather err towards option 1.

Yes, specifying if a field was explicitly requested or just automatically would be useful. Auto fields often are backwards fk/o2o/m2m and primary key.

Are you saying a property annotated: bool? False if entierly auto-generated, and True otherwise?

wallneradam commented 4 years ago

Yes specifying auto fields would be great as well.

I mean true if you have the annotation for backward relation in the model like:

parameters: ReverseRelation['UserParameter']
grigi commented 4 years ago

I'll see about adding some of this to #206 I'll set the backward relation annotated to True if you explicitly named the backwards relation. Right now we ignore the declared reverse relations, as they are only for enabling type hinting at this stage.

grigi commented 4 years ago

No, #206 is big enough, I'm going to merge it and do a new PR. So many things needing my attention at this time, I'll have to draw up a priority list.

grigi commented 4 years ago

Is it OK to assume that an explicitly defined field (e.g. IntField) is a properly annotated field? Then annotated can only be False for reverse relations (FK/O2O/M2M)?

grigi commented 4 years ago

Oh, and what do we do for an autogenerated id PK field? You'd want to know if that is auto or not? So is annotated possibly the wrong thing? are you looking for explicitly defined? Or maybe both?

As in a auto_definition which would only be true if field has been automatically defined (or explicit?), and annotated it it has been manually annotated?

Or should we report the manual annotation? e.g: explicit → If it has been explicitly setup via either a field or as a related_field annotation → Manual type annotation.

Or am I missing the point here?

grigi commented 4 years ago

Released v0.15.6 with ability to disable the reverse relation for FK/O2O. (so half the work on this issue)

merlinz01 commented 4 months ago

Wouldn't it be more "pythonic" to use related_name=None instead of related_name=False? Just a thought.