[Django] #36622: FileField.__init__ is triggering storage LazyObject resolution at boot time

[Django]

#36622: FileField.__init__ is triggering storage LazyObject resolution at boot time
-------------------------------------+-------------------------------------
Reporter: Fabien MICHEL | Type:
| Uncategorized
Status: new | Component: Database
| layer (models, ORM)
Version: 5.2 | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
There is this code in `FileField.__init__` :

{{{
self.storage = storage or default_storage
}}}

The problem is that if we want to have a LazyObject as storage for the
field, it is still resolved at boot time, and it seems unecessary to
trigger resolution at this moment. This seems not expected as the
documentation itself suggest to use LazyObject in case we require a
callable to be overridable during tests :
https://docs.djangoproject.com/en/5.2/topics/files/#using-a-callable

Using `storage or default_storage` is calling `storage.__bool__` which
trigger resolution on default LazyObject.

A solution would be to change this line by :

{{{
self.storage = storage if storage is not None else default_storage
}}}



A workaround for the case specified in the documentation is to override
__bool__ on LazyObject so it always returns True.



{{{
class OtherStorage(LazyObject):
def _setup(self):
self._wrapped = storages["mystorage"]

def __bool__(self):
return True
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/36622>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#36622: FileField.__init__ is triggering storage LazyObject resolution at boot time
-------------------------------------+-------------------------------------

Reporter: Fabien MICHEL | Owner: (none)
Type: Bug | Status: new
Component: Database layer | Version: 5.2
(models, ORM) |
Severity: Normal | Resolution:

Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Fabien MICHEL):

* type: Uncategorized => Bug

--
Ticket URL: <https://code.djangoproject.com/ticket/36622#comment:1>

[Django]

#36622: FileField.__init__ is triggering storage LazyObject resolution at boot time
-------------------------------------+-------------------------------------
Reporter: Fabien MICHEL | Owner: (none)
Type: Bug | Status: new
Component: Database layer | Version: 5.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Description changed by Fabien MICHEL:

Old description:

> There is this code in `FileField.__init__` :
>
> {{{
> self.storage = storage or default_storage
> }}}
>
> The problem is that if we want to have a LazyObject as storage for the
> field, it is still resolved at boot time, and it seems unecessary to
> trigger resolution at this moment. This seems not expected as the
> documentation itself suggest to use LazyObject in case we require a
> callable to be overridable during tests :
> https://docs.djangoproject.com/en/5.2/topics/files/#using-a-callable
>
> Using `storage or default_storage` is calling `storage.__bool__` which
> trigger resolution on default LazyObject.
>
> A solution would be to change this line by :
>
> {{{
> self.storage = storage if storage is not None else default_storage
> }}}
>

>
> A workaround for the case specified in the documentation is to override
> __bool__ on LazyObject so it always returns True.
>

>
> {{{
> class OtherStorage(LazyObject):
> def _setup(self):
> self._wrapped = storages["mystorage"]
>
> def __bool__(self):
> return True
> }}}

New description:

There is this code in `FileField.__init__` :

{{{
self.storage = storage or default_storage
}}}

The problem is that if we want to have a LazyObject as storage for the
field, it is still resolved at boot time, and it seems unecessary to
trigger resolution at this moment. This seems not expected as the
documentation itself suggest to use LazyObject in case we require a
callable to be overridable during tests :
https://docs.djangoproject.com/en/5.2/topics/files/#using-a-callable

Using `storage or default_storage` is calling `storage.__bool__` which
trigger resolution on default LazyObject.

A solution would be to change this line by :

{{{
self.storage = storage if storage is not None else default_storage
}}}



A workaround for the case specified in the documentation is to override
`__bool__` on `LazyObject` so it always returns True.



{{{
class OtherStorage(LazyObject):
def _setup(self):
self._wrapped = storages["mystorage"]

def __bool__(self):
return True
}}}

--

--
Ticket URL: <https://code.djangoproject.com/ticket/36622#comment:2>

[Django]

#36622: FileField.__init__ is triggering storage LazyObject resolution at boot time
-------------------------------------+-------------------------------------
Reporter: Fabien MICHEL | Owner: (none)
Type: Bug | Status: new
Component: Database layer | Version: 5.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Sarah Boyce):

Related #36504
--
Ticket URL: <https://code.djangoproject.com/ticket/36622#comment:3>

[Django]

#36622: FileField.__init__ is triggering storage LazyObject resolution at boot time
-------------------------------------+-------------------------------------
Reporter: Fabien MICHEL | Owner: (none)

Type: Bug | Status: closed

Component: Database layer | Version: 5.2
(models, ORM) |

Severity: Normal | Resolution: duplicate

Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Sarah Boyce):

* resolution: => duplicate
* status: new => closed

Comment:

Thank you for the ticket! I have tested and I agree with this approach.
Given there were some efforts started in #36504, I have added a comment
there and marking this as a duplicate to try and prevent
contradictory/overlapping effort
--
Ticket URL: <https://code.djangoproject.com/ticket/36622#comment:4>