Opened 15 years ago

Closed 12 years ago

Last modified 8 years ago

#10664 closed New feature (wontfix)

non-serializing fixtures

Reported by: Luc Saffre Owned by: nobody
Component: Core (Serialization) Version: 1.0
Severity: Normal Keywords: fixtures
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: yes
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (8)

comment:1 by Jacob, 15 years ago

Triage Stage: UnreviewedDesign decision needed

comment:2 by Kegan Gan, 15 years ago

+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().

comment:3 by Luc Saffre, 15 years ago

Needs documentation: set

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

Last edited 13 years ago by Luc Saffre (previous) (diff)

comment:4 by Thejaswi Puthraya, 15 years ago

Component: django-admin.pySerialization

comment:5 by Seth Buntin, 13 years ago

Severity: Normal
Type: New feature

in reply to:  3 comment:6 by Luc Saffre, 13 years ago

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

comment:7 by Aymeric Augustin, 12 years ago

Easy pickings: unset
Resolution: wontfix
Status: newclosed
UI/UX: unset

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.

Last edited 12 years ago by Aymeric Augustin (previous) (diff)

comment:8 by Luc Saffre, 8 years ago

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.

Note: See TracTickets for help on using tickets.
Back to Top