On Thu, Jun 7, 2012 at 12:17 PM, Andrew Godwin <and...@aeracode.org> wrote:
> Hi everyone, > > As part of my planning for adding schema alteration/migrations into > Django proper, I need to make a few changes to Fields to allow for > better serialisation of model definitions (pretty much a requirement for > any change-detecting migrations system). > > In particular, I propose: > > - Requiring that all fields expose a method which says how to > reconstruct them. > > Essentially, it returns the positional and keyword arguments you would > have to pass into the constructor to make the field again (as there's no > way to get them directly). For those familiar with south_field_triple, > it would be a bit like that. > > This sounds similar to pickling's __getinitargs__, is there anyway we can reuse some of: http://docs.python.org/library/pickle.html#object.__getinitargs__ Alex > There will have to be some restrictions on what can be returned as valid > values - no values that are pre-made anonymous functions, for example - > but that can be cleared up later. > > > - Requiring all fields to be accessible by only their app label and > class name/other unique name. > > This means either having to register custom fields (like admin classes, > for example), or requiring fields to live in a fields.py or fields > package (like models and models.py). This is to provide for a > less-fragile way of referring to them than their full module path (which > might change based on project name or package location). > > Neither of these two options is perfect - registration means a little > more "boilerplate" code, while requiring them to be in a certain module > is going to hurt apps that don't have them there already. For that > reason, I prefer the registration approach - it will only be one extra > line per field, it's a pattern already used for admin classes and > filters/tags, and it will allow for field classes to be renamed while > keeping the same registered name (if someone wants). > > I'd appreciate feedback on these general ideas - a more concrete API > proposal will come later along with details about how I plan to approach > the rest of the problem, but this is one of the few direct changes to > Django's core and so needs dicussion first. > > 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. > > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- 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.
