#29049 closed New feature (fixed)
Add slicing notation to F expressions
| Reported by: | Matthew Pava | Owned by: | Nick Pope |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | slice F |
| Cc: | Adam Johnson, josh.smeaton@… | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
For fields that are string expressions, the slicing notation should utilize database functions Substr, Left, and Right. Those functions could even be deprecated to require the use of slicing notation.
For fields that are iterable expressions, such as ArrayFields or HStoreFields, those could utilize slicing notation in a Pythonic manner.
Change History (28)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
I think this is a reference to my post on the developers mailing list.
That would be F('textfield')[0:5] which would map to SubStr and F('arrayfield')[0:10] which would map to PostgreSQL arrayfield[1:10].
comment:3 by , 7 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:4 by , 7 years ago
| Cc: | added |
|---|
comment:5 by , 7 years ago
| Needs documentation: | set |
|---|---|
| Needs tests: | set |
| Owner: | changed from to |
| Status: | new → assigned |
comment:6 by , 7 years ago
| Cc: | added |
|---|
comment:8 by , 7 years ago
| Needs documentation: | unset |
|---|---|
| Needs tests: | unset |
comment:10 by , 6 years ago
| Owner: | changed from to |
|---|
Taking over this since the current asignee hasn't worked on it in a while.
comment:11 by , 6 years ago
| Patch needs improvement: | unset |
|---|
comment:12 by , 5 years ago
| Needs tests: | set |
|---|---|
| Patch needs improvement: | set |
comment:13 by , 4 years ago
| Cc: | added |
|---|
comment:14 by , 4 years ago
| Owner: | removed |
|---|---|
| Status: | assigned → new |
Since feedback on the review came 10 months after I submitted the patch, and it now has been more than a year since it was submitted, it would be too much of an effort for me to put my mind into this again and get it into a mergable state.
comment:15 by , 4 years ago
| Owner: | set to |
|---|---|
| Status: | new → assigned |
comment:16 by , 3 years ago
| Owner: | changed from to |
|---|
comment:17 by , 3 years ago
| Cc: | removed |
|---|
comment:18 by , 3 years ago
| Needs tests: | unset |
|---|---|
| Patch needs improvement: | unset |
comment:19 by , 3 years ago
| Needs tests: | set |
|---|---|
| Patch needs improvement: | set |
comment:20 by , 3 years ago
| Needs tests: | unset |
|---|
comment:21 by , 2 years ago
| Owner: | changed from to |
|---|
comment:22 by , 2 years ago
I have been reading up about this issue to continue and finish it off from where David left it, and I have some doubts. The SQL query left by Felix in this comment also doesn't generate any QuerySet or objects. I tried to run that query using Manager.raw(), which generated no results.
Further I investigated the resolve_expression method of SliceableF class in django/db/models/expressions.py, and compared it to other implementations of resolve_expression method in other classes but couldn't find anything concrete which might point to where the error might be.
Does a special method for handling slicing and indexing for OuterRef query need to be written so it is properly resolved? That is what I'm thinking because I can't find anything else that is properly handling slicing for OuterRef Queries, unless I'm missing something.
Also should None be used instead of '' in slice_expression for end if length is not provided?
comment:24 by , 2 years ago
| Patch needs improvement: | set |
|---|
comment:25 by , 12 months ago
| Owner: | changed from to |
|---|---|
| Patch needs improvement: | unset |
New PR with some fixes. Hopefully we can finally get this over the line...
comment:26 by , 12 months ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
Could you give an example of what the syntax would look like?