non-serializing fixtures

[Luc Saffre]

I think that a new "non-(de)serializing" type of fixtures might be useful.
If loaddata finds a fixture of this type, then it simply executes it, assuming it is valid Python code.
Example of how such a fixture might look:

from myapp import MyModel
def add_mymodel(field1,field2,field3):
    MyModel(field1,field2,field3)

add_mymodel("a",1,True)
add_mymodel("b",2,True)
add_mymodel("c",3,True)

This example is only one possible application; in fact the programmer is free to write more sophisticated scripts, for example fetch data from different external sources (including csv files), or fill the database with randomly generated data,..

Such fixtures would offer the special characteristic that they execute custom save methods.
They would of course be slower than normal fixtures.

We can also extend dumpdata to support this format, outputting python code as in the example above.
This would be useful when converting a database after model changes.

[Kegan Gan]

+1 for this feature.

Extremely useful when preparing fixtures for tests. During development, it's common to tweak your models. Non-serializing fixtures would allow preparation for test fixtures much easier, faster, and cleaner.

The real use case for me (which I am facing now), is non-serializing fixtures would execute model custom save(), which ensure the model instance's states are intact. Otherwise, I would have to create a lot of corresponding "data", that would have been created in model custom save().

[Luc Saffre]

Django is great! It took me less than 2 hours to write a solution for this ticket!

The ticket is marked “Design decision needed”, but my proposed solution doesn’t require any Django patch. It uses the fact that Django lets you declare your own Serializers.

Here is my proposed solution:
​http://lino.saffre-rumma.net/topics/dpy.html

[Luc Saffre]

Replying to lsaffre:
The previous link had become invalid.
I updated my documentation which is now at
​http://lino.saffre-rumma.net/topics/dpy.html

[Aymeric Augustin]

Django provides ​an extension point to support custom (de)serializers, and you've used it successfully to implement this as a third party module.

However, it may not be an improvement to merge it in Django, because that would put severe constraints on further developments. Also, there's a lot of flexibility in Python code, and I'm not sure we can find a one-size-fits-all design.

If you think still it would be a good idea to include a reasonably generic implementation of this concept in Django, could you send a proposal to the django-developers mailing-list?

EDIT: I just noticed Lino is licensed under the GPL, so we can't merge it anyway.

[Luc Saffre]

The documentation link has changed again, it is now here: ​http://lino-framework.org/topics/dpy.html
and BTW Lino is meanwhile BSD licensed, but I did not yet invest any time into working out a completely independent module.