Hi all - I’m trying to use the ‘natural_keys’ settings for serialization.
I thought I was pretty clever defining ‘natural_key_fields’ as a tuple to be listed in each child model with one generic implementation of “natural_key” for any model and “get_by_natural_key” for models.Manager. All models in the project inherit from classes with these two additions (my own BaseModel and DiscreteManager). But I have run aground setting natural_key.dependencies, which is a list of strings defining the entities that should be serialized before the current model. There are two parts:
- First, all the real children of BaseModel don’t take well to being given ‘natural_key.dependencies = ’ in the class definition, because natural_key is not defined, despite the inheritance meaning it is there when called. I’m not sure if inherited code is ‘there’ in the same way as explicit code; perhaps the children just have pointers to the parent code. If so, how can I set natural_key.dependencies for child classes where I don’t want to make an explicit ‘def’ of the natural_key function?
- Second, my motivation for trying to DRY the natural_key functions was that our team develops and trials apps with pretty high turnover. The apps are distinctive UI experiments for different domains, and may come to me developed by people on a minimal django installation rather than built to fit the whole site. I wanted to minimise the amount of revision required to enroll an app as part of the overall site - if I could just swap in BaseModel for anywhere someone has used models.Model, it would save us all some work and keep the standalone and integrated versions of the code closer together. Is there a way I could define a function to get_natural_key_dependencies that looks for non-nullable foreign keys (and one-to-ones etc) and assembles the precedence list of the schema graph?
- Third, this is all to avoid problems with primary key clashes on dumpdata and loaddata. Dumping with primary keys and even natural-primary has worked well, but if the foreign_key fields are still referring to the ‘id’ field, its not so helpful.
There are entities with relationships to contenttype, and others with relationships to Group from the auth app, which means excluding contenttypes or auth is not really feasible while retaining db integrity. I’d really like to be able to load fixtures for testing, but I am not succeeding.