Skip to content

Conversation

SirAbhi13
Copy link
Contributor

Ticket 29049

Referenced PR: #14731

Continued the previous PR from where it was left of.
Fixed the wrong SQL query that was being generated for OuterRef.
I removed the test test_slicing_of_f_len because even if I was testing with sliced arrays generated through Slice Transformations, the error persisted, perhaps need to open another ticket for it?

Other than that PR looks good to me.

@ngnpope
Copy link
Member

ngnpope commented Nov 20, 2022

Please look at my comments regarding use of None instead of "" for self.end on the previous PR. This hasn't been considered yet.

@SirAbhi13
Copy link
Contributor Author

Please look at my comments regarding use of None instead of "" for self.end on the previous PR. This hasn't been considered yet.

Hi Nick,
I actually did try to implement replacing "" with None for self.end, the way you proposed in the previous PR, but it ended up breaking the code later in the execution. So my question is should I just do it like this

if self.end is None:
          return f"{lhs}[%s:%s]", params + [self.start, self.end]
      else:
          return f"{lhs}[%s:]", params + [self.start]

because None is not expected by compiler.py later and ends up not working.

@ngnpope
Copy link
Member

ngnpope commented Nov 21, 2022

Thanks for looking @SirAbhi13. I did get that working as there were two placed that needed to be updated.

I've been having a further look into this and have some reservations about the design. Going to have a little play to see if I can think how this might work better.

@SirAbhi13
Copy link
Contributor Author

SirAbhi13 commented Nov 27, 2022

I did end up getting the None value working, turns out I was making a mistake during testing on my part.
May I know which part in the suggested changes you have reservations about?

The tests that are failing are for mysql and maria db, because they are evaluating the queries in case insensitive mode, hence returning values in testcases where empty queryset is expected. I Will have to research on how to prevent that.

@ngnpope

@SirAbhi13
Copy link
Contributor Author

Hi @ngnpope, were you able to have any thinking about the design proposed here? Any suggestions to move this forward get this solved? 🤔

@ngnpope
Copy link
Member

ngnpope commented Dec 11, 2023

Hey @SirAbhi13. I think quite some time has passed so I've lost track of where I was going with that thought.

I did find a local branch with a bunch of fixes though, so I've polished that off and put up #17596 to get this over the line.

Thanks for the reminder and your efforts to help push this forward. Quite the number of co-authors on this one!

@ngnpope ngnpope closed this Dec 11, 2023
@SirAbhi13
Copy link
Contributor Author

@ngnpope Glad to have helped! I think the issue with MariaDB and mysql still needs to be looked at as I mentioned in my earlier comment regarding case sensitivity (IIRC) and I wasn't able to find any solution for this.

ngnpope added a commit to ngnpope/django that referenced this pull request Dec 29, 2023
Supersedes PRs django#9670, django#11208, django#14731, and django#16310.

This adds the following changes over the previous PRs:

- Used `None` to omit `end` in `ArrayField.slice_expression()`
- Handled nested slicing, e.g. `F("name")[1:][:5]`
- Simplified `.resolve_expression()`
- Renamed `SliceableF` to `Sliced`
- Clarified some inline comments

Co-authored-by: Priyansh Saxena <[email protected]>
Co-authored-by: Niclas Olofsson <[email protected]>
Co-authored-by: David Smith <[email protected]>
Co-authored-by: Mariusz Felisiak <[email protected]>
Co-authored-by: Abhinav Yadav <[email protected]>
@SirAbhi13 SirAbhi13 deleted the 29049ticket branch December 30, 2023 12:13
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