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

Update Tests #2

Open
Weltschmerz-dev opened this issue Sep 23, 2024 · 2 comments
Open

Update Tests #2

Weltschmerz-dev opened this issue Sep 23, 2024 · 2 comments

Comments

@Weltschmerz-dev
Copy link
Collaborator

  • test_filter_in_list: weerspiegelt de relatie incorrect. moet externe functie worden is_in() of dergelijke

    def test_filter_in_list(self):
    names_list = ["John Doe", "Jane Smith"]
    result = self.query.filter(lambda x: x.name.__contains__(names_list)).select(lambda x: x.name).get()
    for record in result:
    self.assertIn(record['name'], names_list)

  • test_filter_ilike: kan worden vereenvoudigd tot "john" in x.name

    def test_filter_ilike(self):
    result = self.query.filter(lambda x: x.name.__contains__("john")).select(lambda x: x.name).get()
    for record in result:
    self.assertIn("john", record['name'].lower())

@Weltschmerz-dev
Copy link
Collaborator Author

We should extend this issue to cover all the other missing search operators, including:

- like
- not like
- ilike
- not ilike
- in
- not in
- =?
- child_of
Source: Cybrosys: How to use search domain operators in Odoo 17

For consistency, we can handle like and in by overriding Python's contains method. However, cases like ilike will likely require a custom function due to their specific behavior.

To maintain clarity and reduce complexity, we should standardize on either overriding default operators or using custom functions for all cases, rather than mixing the two approaches.

What do you think @Bert-Proesmans ?

@Bert-Proesmans
Copy link
Contributor

To maintain clarity and reduce complexity, we should standardize

I don't think standardizing is a way forward at this point. Experiment with different API methods and see what sticks best.
Other than using a freestanding function that wraps internal methods on the proxy types, I have no idea.

My mind is hung up on the fact that executing the lambda is required to parse its syntax, I'm gonna experiment further into the direction that eliminates that aspect. This doesn't explicitly solve how to implement the advanced operators, but will have some overlap.

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

No branches or pull requests

2 participants