#django

am I supposed to add my migrations to VC, or should they be generated on the machine whenever I do a release?

Migrations should be version controlled, otherwise there'd be no history.

mattmcc: alright, thanks!

When should I implement Model.clean() vs Model.save()? I want to make sure that a flag I have (is_advisor) doesn't conflict with a ManyToMany relationship (advisees). Which is the right place to check that?

I **believe** model.clean() only gets called when you use model forms

I might be wrong

The docs say that save() does not call clean()

well then there ya go

you're no guaranteed to get a clean() call all the time

will the admin understand a ValidationError raised in save()?

save = guarantee unless you're using an SQL terminal

no you can't throw validationerrors from save

unless you catch them yourself

no guarantee on save for update() either

ah, that might be true...

crap really

lol

OK, I better put that logic in both places then.

ive actually not found a good way to raise validation errors back to forms in the model save routines

one thing ive done is used some middleware to grab the request object inside the model.save() method, then write out a message with message.error(), and **dont** save the object

you'll get an error at the top of the page but not a field-specific error in the form inputs

The way model validation is implemented, it should be run before calling model.save()

There's no mechanism for raising validation errors from save.

ryanhiebert: The admin uses ModelForms, which call model validation.

So you do not need to duplicate your validation.

mattmcc: if i understand correctly, you mean to say that a **responsible user** should run full_clean from his business logic and catch/handle validation errors prior to calling save?

that's the intended development paradigm?

Skandocious: Only if you're calling model.save() directly from your code (not using a ModelForm)

right

got it

I've been using Django for years, and I did not realize I was "supposed" to do that.

can't say that i ever recall calling full_clean manually...

Since if you're not using forms, the right way to communicate validation errors to the user isn't clear.

ryanhiebert: me too

mattmcc: that's true... though it's possible to use **forms** instead of **ModelForms**

in which case it's pretty clear on how errors should be communicated (should look the same as model forms)

but with bare forms you can't call save() so i usually end up pulling out field values and constructing an object piece by piece before calling save

and skipping the full_clean() call (cuz i didnt realize i was expected to call it)

What made you choose to do that over using ModelForm?

but yes i understand the issue-- the model doesn't know where to attach the errors if there's no ModelForm present

mattmcc: sometimes my forms are not a direct representation of a model

That's fine. ModelForms are still forms, you can add other form fields that don't map to the model.

mattmcc: sometimes they're a big mish-mash of many models

Similarly, you can exclude model fields from the form which you don't want to mess with.

Yeah, saving to multiple models, you're pretty much on your own. Unless it's a case where it'd make sense to process one post request with multiple form classes, which isn't that unusual.

E.g, two related objects, but where an inline formset doesn't make sense.

mattmcc: yeah ive done that too, using form_prefix

quick question.. is it not allowed for appname/static to contain subdirectories?

That'd be pretty silly.

Much like with templates, subdirectories provide namespacing for static files.

appname/static/appname/css/this-apps-css.css

Which would be found using {% static "appname/css/this-apps-css.css" %}

ok thanks the reason I'm asking is because I do have that, but collectstatic is blowing up with an error

File "/opt/env/ssbc/lib/python2.7/site-packages/django/core/files/storage.py", line 238, in delete

os.remove(name)

OSError: [Errno 21] Is a directory: '/home/django/ssbc/static/app'

app is my subdirectory

of course if collectstatic wants to delete that, I've got a different issue and should be glad it couldn't unlink a directory

ls

Hmm ok if anyone understands collectstatic really well, please take a look at this error: https://dpaste.de/xhaQ#L40

It seems to copy all my files, but then fails at the end because it wants to unlink a directory in my STATIC_ROOT

a_little_birdie: do you have a dir called app in one static die, and a file of the same name?

a_little_birdie: does the problem happem if you remove everything in STATIC_ROOT ?

I don't think I have more than one directory called app.

Let me try

Um, what does manage.py findstatic "app" say?

Since it thinks it should be a file, you might actually have a file (not directory) of that name inside a static dir somewhere.

Found 'app' here:

/home/django/git/ssbc/ssbc/static/app

wait

oh, ok.. thought you had a static source dir inside your STATIC_ROOT

is that a file or a dir?

it's a directory

No it's not, findstatic wouldn't have 'found' it if it was.