Opened 6 years ago

Closed 4 years ago

#10664 closed New feature (wontfix)

non-serializing fixtures

Reported by: lsaffre 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 (7)

comment:1 Changed 6 years ago by jacob

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 6 years ago by kegan

+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 follow-up: Changed 6 years ago by lsaffre

  • 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.ee/blog/20090415.html

Version 0, edited 6 years ago by lsaffre (next)

comment:4 Changed 6 years ago by thejaswi_puthraya

  • Component changed from django-admin.py to Serialization

comment:5 Changed 4 years ago by sethtrain

  • Severity set to Normal
  • Type set to New feature

comment:6 in reply to: ↑ 3 Changed 4 years ago by lsaffre

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 Changed 4 years ago by aaugustin

  • Easy pickings unset
  • Resolution set to wontfix
  • Status changed from new to closed
  • 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 4 years ago by aaugustin (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top