Hi again,
Below, ">D" are quotations from Daniel's message I'm replying to, and
">R" are from Russell's message that opened this thread.
>D *Regarding FileField*
It took me some time to clear for myself why FileField is a data field, and not
like FK: The point is not where the data is stored and whether the DB field
contents are "it" or just a pointer -- the point is whether another model is
involved. I think this is a key distinction; wording the taxonomy in these
terms can clarify certain other issues. As an example,
>R a) "Pure" data fields - things like CharField, IntegerField, etc. Fields
>R that manifest as a single column on the model's underlying table.
this wording makes it a little unclear (at least to me) if parent fields fall
into this category (as they do not "manifest as a single column on the model's
underlying table"). But the higher-level language, "fields that store primitive
data on the model instance itself" -- with a better word for "primitive", or a
full explanation on what it means -- is something I find much clearer and more
accurate.
>D ImageField is, based on the definition of virtual so far, a virtual field.
Well, as it is not related nor relating, the only virtual field it could be is:
>R e) "Pure" virtual fields - Fields that are conceptual wrappers around other
>R fields on the same model. Virtual fields don't have column representations
>R themselves; they are a wrapper around columns provided by other fields.
But ImageField does have its own column representation. In fact, it is not a
wrapper around the width and height fields in the way that, say,
GenericForeignKey is around the content_type and object_id fields -- if you
change these fields, nothing about the image changes. So, yes, I maintain that
it is a different beast.
>
> On Monday, August 18, 2014 6:50:04 AM UTC+2, Russell Keith-Magee wrote:
> >
> > I agree that conceptually, part of the data for a FileField/ImageField is
> > held "externally"; but it's a different kind of external. From the
> > database's perspective, the record is complete and correct when you're
> > storing a string. The fact that the string represents a file system path
> > is a very significant implementation detail - after all, you need to
> > know to show a file browsing dialog (or whatever UI you want) - but
> > then, the same is true of a date field needing a date picker, and a
> > boolean field needing a checkbox. It doesn't affect the way the database
> > needs to interact with the data it is storing.
> >
As I said above, I think focusing on the database here is a red herring. This
is a model-level API, and we should be focusing on the interactions between
models and fields, and between them and other code.
In that spirit, I think some more relevant categories might be
1) "hidden fields" (the parent_ptr?),
2) "read-only fields" (currently I suspect this only applies to DateTime fields
with auto_now=True, but I can imagine calculated aggregation fields),
3) "fields you shouldn't mess with" (id, parent_ptr, image's width_field and
height_field -- you can edit these, but in all probability you don't want to),
4)"fields you should only edit via API" (passwords)
HTH,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/201408181444.23313.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.
