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

Impelement get_homogeneous_pages. #87

Closed
wants to merge 64 commits into from

Conversation

mattalbr
Copy link

Unit tests forthcoming once we're directionally aligned.

Unit tests forthcoming once we're directionally aligned.
@mattalbr
Copy link
Author

#86

pages = []
for i in range(len(queries)):
rows = page_to_rows[i]
pages.append(paging_queries[i].page_from_rows(rows))
Copy link
Collaborator

Choose a reason for hiding this comment

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

missing a return pages?

Copy link
Author

Choose a reason for hiding this comment

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

Done! Sorry about the lack of polish on this PR. Unit tests will catch them all, I just didn't want to invest in writing a bunch of tests before we knew if we'd be merging this or not :)


# Grab result_type and keys before adding the _page_identifier so that
# it isn't included in the results.
result_type = orm_result_type(query.query)
Copy link
Collaborator

Choose a reason for hiding this comment

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

All these query.querys are a little confusing, I think we should avoid overloading the word "query". Let's rename _HomogeneousPagingQuery -> _PagingRequest and query -> request or similar?

Copy link
Author

Choose a reason for hiding this comment

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

I also hate this (and it's even worse above, with a q.query.query). I riffed a little on your suggestion, let me know what you think!

result_type = orm_result_type(query.query)
keys = orm_query_keys(query.query)
query.query = query.query.add_columns(
sa.sql.expression.literal_column(str(page_identifier)).label("_page_identifier")
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does .add_columns(page_identifier) not work? Given that we're just trying to select an integer value and not a database column, I'm confused about the need for literal_column.

Copy link
Author

Choose a reason for hiding this comment

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

I'll try this, but I believe literal_column is the correct way to insert a literal into a select. It also allows us to give it a label, which is convenient when we do our collation later.

# it isn't included in the results.
result_type = orm_result_type(query.query)
keys = orm_query_keys(query.query)
query.query = query.query.add_columns(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Since we reference query.query multiple times and then modify it, let's split it out into a separate local variable.

Copy link
Author

Choose a reason for hiding this comment

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

Roger

@@ -438,3 +439,87 @@ def get_page(
place, backwards = process_args(after, before, page)

return orm_get_page(query, per_page, place, backwards)


# Do we need to support python 3.6?
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nope, we've dropped support for 3.6 already and I'm happy to drop support for 3.7 if it gives us any friction at all. :)

Copy link
Author

Choose a reason for hiding this comment

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

Love it! dataclass is such a nice improvement from NamedTuple.

@@ -3,6 +3,7 @@
from __future__ import annotations

Copy link
Collaborator

Choose a reason for hiding this comment

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

CI fails at flake8 with a bunch of undefined names - looks like you've forgotten some imports?

page: Optional[Union[MarkerLike, str]] = None


def get_homogeneous_page(queries: list[PageRequest[_TP]]) -> list[Page[Row[_TP]]]:
Copy link
Collaborator

Choose a reason for hiding this comment

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

I definitely think it should be get_homogeneous_pages.

Copy link
Author

Choose a reason for hiding this comment

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

Whoops, typo!

@acarapetis
Copy link
Collaborator

I definitely think some version of this is worth including, since it's not achievable using our current documented public API; so thanks!

I've added a bunch of minor comments in my review above, should be easy fixes. I do have a couple more significant concerns:

  • Since the Query API is now considered legacy, I definitely think we want an equivalent select_homogeneous_pages API to work with Select.
  • Unless I'm mistaken, the _page_identifier column is going to be hanging around on the rows returned to the user, which is not desirable. We already handle this same issue for added keyset columns in orm_page_from_rows, so hopefully we just need to add an additional item to paging_query.extra_columns - let me know if you need help with this.

And yeah, bring on the tests. :)

Copy link
Author

@mattalbr mattalbr left a comment

Choose a reason for hiding this comment

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

I'm almost there, just still struggling with select_homogeneous_pages. It keeps failing trying to grab the keys. Let me know if you see something obvious, otherwise I'll keep fighting with it.

Otherwise, good for you to take another look.

@@ -438,3 +439,87 @@ def get_page(
place, backwards = process_args(after, before, page)

return orm_get_page(query, per_page, place, backwards)


# Do we need to support python 3.6?
Copy link
Author

Choose a reason for hiding this comment

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

Love it! dataclass is such a nice improvement from NamedTuple.

page: Optional[Union[MarkerLike, str]] = None


def get_homogeneous_page(queries: list[PageRequest[_TP]]) -> list[Page[Row[_TP]]]:
Copy link
Author

Choose a reason for hiding this comment

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

Whoops, typo!

pages = []
for i in range(len(queries)):
rows = page_to_rows[i]
pages.append(paging_queries[i].page_from_rows(rows))
Copy link
Author

Choose a reason for hiding this comment

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

Done! Sorry about the lack of polish on this PR. Unit tests will catch them all, I just didn't want to invest in writing a bunch of tests before we knew if we'd be merging this or not :)


# Grab result_type and keys before adding the _page_identifier so that
# it isn't included in the results.
result_type = orm_result_type(query.query)
Copy link
Author

Choose a reason for hiding this comment

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

I also hate this (and it's even worse above, with a q.query.query). I riffed a little on your suggestion, let me know what you think!

# it isn't included in the results.
result_type = orm_result_type(query.query)
keys = orm_query_keys(query.query)
query.query = query.query.add_columns(
Copy link
Author

Choose a reason for hiding this comment

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

Roger

result_type = orm_result_type(query.query)
keys = orm_query_keys(query.query)
query.query = query.query.add_columns(
sa.sql.expression.literal_column(str(page_identifier)).label("_page_identifier")
Copy link
Author

Choose a reason for hiding this comment

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

I'll try this, but I believe literal_column is the correct way to insert a literal into a select. It also allows us to give it a label, which is convenient when we do our collation later.

@mattalbr mattalbr requested a review from acarapetis July 18, 2023 17:48
@mattalbr
Copy link
Author

Closing in favor of #90 which I finally got working for both ORM and select.

@mattalbr mattalbr closed this Jul 20, 2023
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.

2 participants