On May 15, 2017 2:02 PM, "jgomo3" <jgo...@gmail.com> wrote:
I set a models.FilePathField with the path attribute as an instance of an
object implementing __str__. I works well until I needed to get the
corresponding Form Field. It caused the following error:
TypeError: listdir: path should be string, bytes, os.PathLike, integer
or None, not StringSettingsReference
StringSettingsReference is my custom Class I mentioned implements the
__str__ method.
listdir is complaining because there is some code trying to do the
following:
for f in sorted(os.listdir(self.path)):
This code is from `django/forms/fields.py` (Django 1.11).
What I want to point out is that Django allowed me to create a model where
a FilePathField was initialized with a path attribute with type different
from string, bytes, os.PathLike, integer or None; and then, only Form Field
related code complains about that (I was using my app for some time and
realized about this just because decided to reuse the admin site (yes, my
application is not using form so much)).
Django should complain before (not allowing me to create a model like that)
or what would be more convenience for me is to not complains about that.
Working as expected. In general, validation occurs at the form level, not
at the model level. Any input from a user is generally passed through a
form or other process to validate the input before it is attached to the
model.
It sounds like you are assigning a custom object to the model field
manually, which Django does not know how to handle later down the road. If
there is a for loop involved, I don't believe the __str__ method is
invoked, hence the reason you are receiving the exception.
So, I was thinking to fill a bug report, but it is write in the Django
documentation that it is a good idea to ask here before.
Does this qualify as a Bug?
I wouldn't think so. You're treading outside of the expected work flow.
Addendum:
Why am I using an special class anyway?
Because I wanted the path to be relative to a setting variable, but writing
anything but a string in the model definition is not allowed by the
migration serializing mechanism. I mean,
Right, the reason being that the value stored in that field will end up in
a static database field upon a save() call.
TBH, you may want to rethink your approach to this problem. If you are
generating paths relative to a variable, then simple concatenate the given
path and variable accordingly. Keep in mind that the generated value is
what is being stored, so any illusion of a dynamic path would be lost.
If it were me, I'd investigate only keeping the short path (to keep the
original value as long as possible), and adding the variable prefix after
the object is retrieved later, but that may not be possible. It would make
it easy to switch all of your paths to another section of the file system
by changing a single setting. Otherwise you'll be left with modifying the
existing values in the DB in the event of a location change, which can get
messy quickly.
-James
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciWujdByQP%2BsN6v0p3au4NZJpLzQZw43FBMEi%3DctQt0Rtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
