#django

can somebody provide some direction on how it may be possible to inject css or somehow manipulate the wagtail admin templates without forking wagtail?

i have tried dropping modified templates into appname/templates/wagtailadmin/admin_base.html etc, to no avail

is there a good/simple way in django to start creating objects but then only commit them if the whole set of related objects is created successfully?

i'm using postgres

jtri: transaction.atomic()

just not sure how integrated the transaction management is... never used it in django

you can use it as a decorator or context manager, it commits on a succesful exit, and rolls back in case of an exception

not sure what context manager is, but decorator looks good/simple :)

with transaction.atomic(): do stuff

knbk: ah, i see, also good/easy

if I put an atomic decorator on a method, and that method calls another one, I presume the whole stack gets protected?

Hey #django. Quick question: is there a way to see whether my prefetch_related is getting hosed somewhere? I have a prefetch_related and I still get an N+1.

jtri: yes

jo_: look at the queries being made... is it a .all() ?

.filter(blah).prefetch_related('foo')

And in my serializer I've got name = serializers.CharField(source='foo.name')

apparently quitting from pdb doesn't cause a rollback, though... odd?

FunkyBob: I guess if you're asking about _where_, the field is being access inside rest_framework/fields.py get_attribute(71).

jo_: Sure you don't mean select_related? Referring to a singular foo.name doesn't seem like it'd make sense combined with prefetch_related.

Hmm. Maybe.

I have a bunch of objects, each with a reference to a foo, and I want to return foo.name for each of them. I'll try select_related.

If the model you're serializing holds an FK to foo, then select_related is the right direction.

Nope. Still an N+1.

Oh. Let me do select_related('foo__name') instead.

That'd only work if foo had an FK named 'name'

Ah.

It's joining tables for models.

I'm using the django rest framework generic views and trying to associate a user with the object I'm creating, however my perform_create method is never being hit, any advice on why would be greatly appreciated http://dpaste.com/01W8QWE

Well, as it stands, prefetch_related('foo') and fetch_related('foo') both result in one query for each of the objects with a foo.

Kayra: I think I've seen this before. Can you implement def create()?

jo_: Object has no attribute save

Kayra: Try stealing the create method from here and adding it to your model: http://www.cdrf.co/3.3/rest_framework.mixins/Cr...

Just copy and paste def create and add a breakpoint at the start. It's feasible your serializer is not evaluating as valid, so it's not calling your perform_create.

Especially if you're saying the User field can't be null.

jo_: put this into my model? That seems like very bad practice

We're debugging.

Into your endpoint.

jo_: Ah sorry, thought this was the final solution

create is called first, then it calls perform_create.

What we want to do is narrow down why perform_create isn't being called.

This will tell us if it's your serializer that's having problems.

jo_: 'Request' object has no attribute 'save'

I ran into exactly this same problem and that's what was wrong with my code: serializer validation failed because I was trying to add a user in perform_create, but perform_create wasn't being called because the serializer saw user was missing.

Hmm.

jo_: Yeah, isn't there a way to get to the serializer part?

Did you copy and paste the create method exactly?

Kayra: You can override parts of the serializer error checking.

Yes, I copied it exactly into my model

But you shouldn't be seeing "Request has no method save()"

Into your model or into your view?

model

This should go above perform_create in your view.

Ah, I thought you had said model

Thought it was a bit odd

jo_: Same error, {"user":["This field is required."]}

Yup.

So here's what's happening:

Do you see inside create, serializer.is_valid is getting called before self.perform_create()?

Yeah

I'm guessing if we do serializer = self.get_serializer(data=request.data, user=request.user)

1 sec.

Yes. That's feasible.

You can also make a mutable copy of the data with tempdata = request.data.copy() (or was it clone?), then add tempdata['user'] = request.user

But I'm not the boss of you.

Surely this is quite a common thing to do?

I think perhaps the Django Rest Luddites have a correct (tm) way of making this happen, but I don't know a better way.

Feels like a needlessly hacky way

I completely agree.

jo_: Thanks for the help, I'm going to look for the correct way (tm) now that I know what's going on, I'll let you know if I find anything

Much obliged.

Good luck.

Okay, here's my simplified code: http://dpaste.com/2N1X3WG

I guess 'the_id' is too simplified. Let's say 'the_ids'.

So I'm getting a bunch of Foo back. I want bar.name for each foo.

Despite that prefetch (or select_related), I always get one query for each entry.

jo_: I got it working

Nice. What'd you do?

jo_: Well when I initially did I, I followed the tutorial where they specify 'owner'

And I guess I mixed up 'user' and 'owner' somewhere, because you need to tell the db that it's user eventually

So I just changed everything to user

And now it works fine