Hi Shai, Thanks for getting back, so..
On Monday, August 18, 2014 1:44:49 PM UTC+2, Shai Berger wrote: > > 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. > Thanks, will change the docs. > > >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. > That's correct! sorry about that, I am looking at the implementation of ImageField and it looks like the width_field and height_field are optional (is that correct?). >R Pure" virtual fields - Fields that are conceptual wrappers around other fields on the same model. Virtual fields don't have column representations themselves; they are a wrapper around columns provided by other fields. ImageField does have a column representation of it's own and It requires migrations, so this means that it looks nearer to a data field, but where to put it? As you say correctly, it's a beast of it's own. Another solution could be to refactor ImageField to make it 100% virtual compatible, but if we do this it also makes sense to refactor a lot of other ambiguities in the codebase. > > > > > 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/c13c20f1-55b6-47c4-841b-f550abeea1a5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
