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

fix(search): implements changes to search to capture user queries #4471

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

legaltextai
Copy link
Contributor

Makes changes to models, views, adds migrations

Fixes: #4230

Makes changes to models, views, adds migrations

 Fixes: #4230
Copy link
Member

@mlissner mlissner left a comment

Choose a reason for hiding this comment

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

Just a quick review here, but I did find a few things to address. I think you might do well to sit down with Gianfranco and pair program these, but I leave that up to you guys.

Looks pretty good though!

# Create and save the SearchQuery object
SearchQuery.objects.create(
get_params=request.GET.urlencode(),
query_time_ms=render_dict.get("query_time", 0),
Copy link
Member

Choose a reason for hiding this comment

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

I think I'd set this to null if we don't have the value, or if the called function always returns the value, I'd do:

Suggested change
query_time_ms=render_dict.get("query_time", 0),
query_time_ms=render_dict["query_time"],

By doing that, you'd enforce the calling function to always deliver on its promise.

SearchQuery.objects.create(
get_params=request.GET.urlencode(),
query_time_ms=render_dict.get("query_time", 0),
hit_cache=render_dict.get("hit_cache", False),
Copy link
Member

Choose a reason for hiding this comment

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

Similarly, defauling to False here seems a bit weird if we know the value will always be in render_dict.

@@ -514,41 +519,59 @@ def show_results(request: HttpRequest) -> HttpResponse:
if not is_bot(request):
async_to_sync(tally_stat)("search.results")

# Perform the search
search_type = request.GET.get("type", SEARCH_TYPES.OPINION)
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason you tweaked the case statement into an if/else, and moved it up here?

Comment on lines +52 to +60
class SearchQuery(models.Model):
date_created = models.DateTimeField(auto_now_add=True, db_index=True)
date_modified = models.DateTimeField(auto_now=True, db_index=True)
get_params = models.CharField(max_length=255)
query_time_ms = models.IntegerField()
hit_cache = models.BooleanField()

def str(self):
return f"Query: {self.get_params} at {self.date_created}"
Copy link
Member

Choose a reason for hiding this comment

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

Getting models exactly right is important because DB migrations are annoying, so I have a few comments here:

  1. We can use AbstractDateTimeModel to automatically add the date-created and date_modified fields.
  2. We'll want full descriptions of each field, as in other models.
  3. In postgresql, you don't get a performance boost by doing max_length, and I can promise you that some queries will be really long. I'd remove that so that long queries don't crash things.
  4. We'll want to link these queries to users, so we'll need a FK to them (there are lots of examples).
  5. The documentation isn't (yet) clear about this, annoyingly, but db_index is considered the old way of adding an index. These days, they should go into the Meta class.

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.

Save and expose user search history
2 participants