Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OneToOneField #239

Merged
merged 22 commits into from Nov 28, 2019
Merged

OneToOneField #239

merged 22 commits into from Nov 28, 2019

Conversation

sinaso
Copy link
Contributor

@sinaso sinaso commented Nov 16, 2019

I implemented most of what is required to make OneToOneField working both in prefetch and lazy mode. I have tested most cases, although there is no unit tests yet. Just wanted you to take a look and comment. It may not be completely ready to be merged yet though.

thanks
--sina

@sinaso sinaso changed the title One2onefield OneToOneField Nov 16, 2019
@coveralls
Copy link

coveralls commented Nov 16, 2019

Pull Request Test Coverage Report for Build 1044

  • 106 of 107 (99.07%) changed or added relevant lines in 8 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.04%) to 98.12%

Changes Missing Coverage Covered Lines Changed/Added Lines %
tortoise/fields.py 20 21 95.24%
Totals Coverage Status
Change from base Build 1040: 0.04%
Covered Lines: 6416
Relevant Lines: 6482

💛 - Coveralls

@coveralls
Copy link

Pull Request Test Coverage Report for Build 1002

  • 33 of 100 (33.0%) changed or added relevant lines in 6 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-2.1%) to 94.449%

Changes Missing Coverage Covered Lines Changed/Added Lines %
tortoise/fields.py 9 21 42.86%
tortoise/backends/base/executor.py 5 18 27.78%
tortoise/models.py 13 28 46.43%
tortoise/init.py 3 30 10.0%
Totals Coverage Status
Change from base Build 992: -2.1%
Covered Lines: 6171
Relevant Lines: 6455

💛 - Coveralls

self._do_prefetch(instance_list, field, related_query)
for field, related_query in self._prefetch_queries.items()
]
await asyncio.gather(*prefetch_tasks)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍
Yes, since we are now properly concurrency safe, we should probably do more I/O concurrently instead of in loops

fields.BackwardFKRelation,
fields.BackwardOneToOneRelation,
),
):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably extend the field definition by addind a "o2o_fields" list instead. o2o may be implemented much like foreign keys, but are conceptually different. So lets keep them separate in describe_model

@@ -181,11 +182,12 @@ def _get_table_sql(self, model, safe=True) -> dict:
else ""
)
# TODO: PK generation needs to move out of schema generator.
if field_object.pk:
if field_object.pk and not isinstance(field_object.reference, OneToOneField):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is OK for now, but we should remember to fix this in #206

Copy link
Member

@grigi grigi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good so far, Do you need help with the unit tests?

@sinaso
Copy link
Contributor Author

sinaso commented Nov 17, 2019

Thank you @grigi . I will try unit tests, will let you know if help was needed.

@sinaso
Copy link
Contributor Author

sinaso commented Nov 25, 2019

@grigi please take a look. Added test to cover the added code.

@grigi
Copy link
Member

grigi commented Nov 26, 2019

I'll have a look today :-)

@grigi
Copy link
Member

grigi commented Nov 27, 2019

I have a question, form a user's pov, is there such a thing as a backward One-to-One field? The behaviour should be identical to forward foreign key, right?

As in await model.o2ofield and await othermodel.o2orevfield ?

@grigi
Copy link
Member

grigi commented Nov 27, 2019

Beautiful PR 👍

Could I ask that you add yourself to CONTRIBUTORS and a quick description of the change in CHANGELOG? (e.g. section 0.15.2)

The only change I could request is to merge "o2o_fields" & "backward_o2o_fields" in the describe model. As the user would use them symmetrically. Kind of like how m2M is used symmetrically.

One can still see by the type of "Backward..." how the one is implemented if you really NEED to know.

Otherwise: Awesome work! 😎

@sinaso
Copy link
Contributor Author

sinaso commented Nov 27, 2019

Thanks @grigi !

I can merge "o2o_fields" & "backward_o2o_fields" but before that, let's make sure if it is not going to be confusing down the road. Note that, contrary to M2M case, our fields on O2O are not really symmetric.

For one, in the underlying tables, backward table does not have any columns while the forward table has a column pointing to the other table. This asymmetry is also reflected in the models themselves, setting the o2o value in the forward object, means we are changing the associated column in the table, while changing the backward o2o value should be avoided (hmm, I still had to put a setter for the lazy case, but now I am thinking I need to disallow users to set the backward relation)

my guess is because of this asymmetry pretty much in all cases users might need to distinguish between forward and backward o2o even if we merge them into one.

I would be happy to discuss this more if needed, but if you feel confident, I can go ahead to merge them.

@grigi
Copy link
Member

grigi commented Nov 27, 2019

Right, so not entirely symmetrical. One can set the o2o relation from one side only, but read from both sides the same.

Is there anything you feel you need to do before I merge?

@sinaso
Copy link
Contributor Author

sinaso commented Nov 27, 2019 via email

@sinaso
Copy link
Contributor Author

sinaso commented Nov 28, 2019

@grigi I think this should do...
Thank you

@grigi
Copy link
Member

grigi commented Nov 28, 2019

Awesome PR 👍 Merging now.

@grigi grigi merged commit 379cd71 into tortoise:develop Nov 28, 2019
@grigi
Copy link
Member

grigi commented Nov 28, 2019

Release 0.15.3 with this changes :-)

@sinaso
Copy link
Contributor Author

sinaso commented Nov 28, 2019

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants