On Sat, Nov 7, 2009 at 8:37 AM, Rob Madole <robmad...@gmail.com> wrote:
>
> (accidentally sent this directly to Russell, he has offered to help me
> re-construct this where it belongs)
(and, repeating my response that got sent privately to Rob)
> I am under-the-covers-down-and-naughty familiar with this one.
>
> This one has caused pain for us. We had a situation very similar to
> what #7052 outlines and I ended up forking Django just to solve it and
> implementing the attached patch. So, from my selfish point of view I
> don't care where this one ends up I just want:
>
> # To not fork Django
> # To have my tests work
Fear not - my intention is that *something* will get into v1.2. I've
started this discussion to try and work out if there is anything
simple we can do for the serialization case, but if we can't come to a
consensus, I'm more than happy to commit just the Option 1,
deserialization only solution.
>> class Meta:
>> ...
>> dump_related = ('app_label','model')
>>
>> which indicates the two fields that should be used to construct the
>> lookup dictionary whenever a ContentType object is serialized.
>>
>> The problem with this approach is that hard-codes a single aspect of
>> serialization into the model. If someone has a different set of
>> requirements for serializing content types under particular
>> circumstances, they will be out of luck.
>>
>
> -1. But it DOES work. And it works really well. If I remember
> correctly, part of the work the patch does is alter the ContentType
> model to add the dump_related exactly as you mentioned.
Correct. If a Meta option was the best option, the patch on the ticket
is pretty much pret-a-porter. However, "it works" isn't really the
quality bar we're aiming for :-)
> I wonder how nasty it would be if ContentType and Permission used this
> in a very undocumented way until the major serialization re-write
> could be accomplished.
This is an interesting approach. My only hesitation is that, I'm not
sure how I feel about introducing a temporary option, not documenting
it, and then sorta-kinda encouraging people to use it. However, if we
approach the documentation process carefully, it might be manageable
(maybe introduce it into the docs, but marking it as deprecated from
the start)
>> Option 3: Add flags/arguments to the serializer to control dynamic dumping
>> ---------------------------------------------------------------------------
>> ---------------------------------
>>
>> i.e.,
>> ./manage.py dumpdata myapp --format=json --indent=2
>> --lookup=contenttypes.contenttype(app_label,model)
>>
>> It might be possible to simplify this a little by saying that when
>> --lookup=contenttypes.contenttype is specfied, the first
>> unique_together tuple will be used to construct the lookup.
>>
>> This puts complete control in the hand of the user at serialization
>> time. However, the syntax isn't especially elegant, especially given
>> that every single serialization of contenttypes and permissions will,
>> in practice, need to use the --lookup argument.
>>
>
> My concern for this one is forgetting to add the option every time I
> dump the fixtures. (Which is quite often in our environment). I
> would end up writing my own management command to wrap this so I
> wouldn't forget.
This is also my primary concern with this technique.
> Let's say dump_related is out in the Model class, I agree this is not
> where this belongs. What if we had a slightly altered way of
> describing it. In it you could have something like this:
>
> from django.contrib.contenttypes.models import ContentType
> from django.core.serializers import register_serializer_style
>
> register_serializer_style(ContentType, related=('app_label',
> 'model',))
>
> I could put this one-liner anywhere. I would probably put it in my
> models.py right after the class definition, or I might put it in the
> project itself and leave it out of the app altogether. The important
> thing is it gets it out of the Model class definition Meta section.
> It could also be last-in wins, so if my way of serializing ContentType
> differs from the default (which might be built-in to contrib) I could
> change it somewhere else. I can't think of a good use case for why
> you would need to serialize it differently but Russell did mention it
> as a possibility.
And that's exactly what I've got in my mind's eye for Option 4 - the
complete rewrite. However, I don't want to commit to part of an API
without knowing what the rest of the API will look like.
> One feature that we've been playing with is using a Python module to
> seed our serialization. It looks something like this:
>
> from django.contrib.auth.models import *
> from myproject.models import *
> from myproject.utils.serializer import S #'S' for "seed"
>
> seed = (
> S(User.objects.filter(staff_status=false)),
> S(Group.objects.all()),
> S(Permission.objects.all()),
> S(BlogEntry.ojbects.all()[:200], recursive=False),
> )
>
> Our system is complex enough that we need to dump subsets of data,
> filter by date, and some other junk before we ultimately pass it to
> the serializer. I would like to see something like this added to the
> next version as well.
This sounds like it might be out of scope for v1.2 (simply because
this is a completely new idea that hasn't been discussed before).
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
