On 07/06/12 21:56, Anssi Kääriäinen wrote: > Is the reason for this to be able to track changes to field by > checking if its init arguments have changed? Why is it not possible to > track changes by checking the SQL output the field will generate > instead? This is guaranteed to be a string, and should be readily > available for any field. I am just trying to get up to speed here...
No, it is so a model can be instantiated for any point in time (essentially a versioned ORM). This is needed so that any custom python/ORM code in migrations see the models as they were when they were created, and thus won't get weirded out by the columns not matching. There was a decent explanation about why and how models are resurrected like this on south-users ages ago, but I think that post may have been lost to the voids of time. (Also worth pointing out: fields don't have just one SQL definition, they can have many - not only for different database backends, but also different ones for creation-with-the-table and being-added-later). > As an idea, why not mimic the models.Model.__new__. You could have > Field.__new__ which does the registration. A field could have > app_label and "field name" as Meta (or just base level arguments). If > these are not supplied, they will be generated by the __new__ from the > field's class.__name__ and module. Once backwards compatibility period > is over the meta variables are required. > > Any field which is never imported will never get registered, but I > don't see that as a problem - if the field is not in use in the > project, why should it need to be registered? As some of the other posts argue, that's also quite fragile - I'm not sure there's a guarantee all field classes will be unique (especially as fields have been around for ages). It also needs metaclasses - you can't do it in Field.__new__, you need to do it in the metaclasses' __new__, and if there's one thing I want to avoid it's adding more metaclasses. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
