#django

One of the mantras of Python is that "explicit is better than implicit" right?

I need to use information that the view contains that the form doens't per say, so where in the view would you do that?

(nitpick: 'per se')

dang`r`us: oh, i think that between dbs there is not much difference, unless u had a very specific db for that purpouse (which i dont know of any)

santiago, okay. So do you have any experience with the performance impact? I mean I'm quite sure I'll be fine, but not 100%

okimoyo: get_form_class or wherever the form is initiated and pass that info to __init__ or in is_valid or wherever you want

i would do it in the view

no, sorry :/

mattmcc, to continue our convo about numbers- would you recommend integer for gender?

Were these the genders that you were receiving from some outside data source, so you can't really restrict them to a set choices list?

How would you guys recommend implementing a system where sidebar buttons highlight for descendant pages as well as the pages they directly point to? (Bonus points if I can reuse it in another site I'm porting to Django where the actual content pages have a namespace separate from the various drill-down URL schemes used to reach them)

Ah ok. Is it a good idea to relate (fk) directly to my user model? Its for a clothing store, so there will be times when the user might want to shop a dif gender...?

deitarion: A good navigation app can help you render active parent menu items. I'd checkout django-sitetree.

Thanks. Looking into it now.

mattmcc, or is it better to store the general as a pk with each product? Seems wasteful/repetive?

ycon_: Ah, this must be a different case than the one I'm thinking of.

Backend of a mobile app, ~ 1mill clothing products coming through an API if its relevent

So what are you assigning a gender to? A product? A user?

mattmcc, both have it- user gender from their login (social), and obv clothing belongs to one/the other/ both

And how many distinct values are there? Can the provider of the API data just send along any arbitrary value they want?

No, we'll predefine a few (but they'd be able to change the api's gender/store etc) django-nap fyi

If it's a predefined set, them I'd just use a single-letter choice. (('w', women'), ('m', 'men'))

Within each individual product is fine?

Sure.

One way or another, you have to identify a gender for each product.

So as its' own model (fk with the model)?

No, just a CharField(choices=...)

Oh yep, got it

A model buys you nothing here if the choices are fixed.

In fact, it would slow things down. You'd have a constraint and an index that don't help you.

hm. I assumed that switching on ATOMIC_REQUESTS would cause a rollback of everything saved in a view when that view throws an exception. But apparently I was wrong?

Ok, so I bought a MacBook and set Python/Django on it along with a PostgreSQL database. I ended up screwing something up and had to completely reset my migrations for all my project's apps. Now I pull the app back through source control and migrate won't make the necessary changes on my original machine's database.

What steps did you take to 'reset' your app's migrations?

Basically deleted them all

and ran initial migrations on a fresh database.

Okay. There's two parts to managing migrations, the Python files and a table in the database that tracks the applied state.

does ATOMIC_REQUESTS not work with WizardViews?

Ah okay

But shouldn't my new migrations be named differently than my old ones?

Or did deleting everything screw it up entirely?

I didn't think about the implications of migration python files staying in version control before I cleared everything.

you can delete the migration files too, you know

I did that on the other machine. My fear is if I do that again, it will cause the same problem when I pull the project again on my laptop

I don't want to keep going back and forth

like mattmcc said there is two parts to migrations

I mean, your repo should always be able to bring your db to a consistent state

you might need to zap the db for that to happen, depending on what you did to the migration files

So I need to find that migration history table and drop it?

that depends on your screwup.

but since you cannot pin it down, I'd say the surefire way is zap the db and re-run your migrations

(... after recreating the db)

I'm using GeoDjango and its kind of a pain to set my database up

I was hoping there was an easier way

There is, actually.

I found the django_migrations table

When you create your DB, load all the postgis stuff into the public schema like normal. Then create another schema with the same name as your DB user.

I'm using geodjango too and did what mattmcc recommended a few days ago, it's quite cool

Then, if you want to blow your stuff away, you can drop the schema, not the whole DB.

Oh wow

Postgis stays there.

Yeah that's what I need

This works handily because the default search_path is "$user",public

mattmcc, I could not get that part to work for some reason though

so I created a schema 'django'

and put this in my db options: '-c search_path=django,public'

I've never worked with multiple schemas before. Anything I should watch out for?

works like a charm

astrosoup, zapping DB then becomes: drop schema django cascade; create schema django;

(without that -c option, django would create tables in the public schema)

dang`r`us: Hmm. "create schema authorization <yourdbusername>" ?

mattmcc, I'll try it out ... right now I'm under release pressure

people in #postgres have been very helpful too so I'm sure I can figure this out ...

someday

right after I fix this weird transaction problem

astrosoup: If you're unfamiliar with them, it'd be worth reading a bit. But they're pretty straightforward. http://www.postgresql.org/docs/9.4/static/ddl-s...

Great, thank you so much

hello, I am using celery and ran into an issue where I get a TypeError but Im not sure why? http://dpaste.com/2E3WV8D#line-67

someone told me you can't pass a model instance into a shared_task, is this true? why/

Well, as a general rule you don't want to pass model instances to tasks because of serialization issues.

The model data may be stale by the time the task gets to it, and you're storing a ton of model object attributes that you almost certainly don't need.

You can instead just pass the PK and query it from your task.

mattmcc: ok so whats a suggestion, just serialize it and pass that to the task? or^^ ah yea

I thought of doing that

just pass the id and do a lookup

ok sweet.. thx

lesson learned: ATOMIC_REQUESTS is an option per db, not toplevel settings.py scope

(I'm not quite sure whether I like it this way to be honest)

any reason why geodjango admin uses openlayers and not leaflet?

I mean, not being able to see cities kinda sucks.

but I suppose it's "just" a matter of configuring the template

sigh :)

Patches welcome? :)

But there is django-leaflet already, so. https://github.com/makinacorpus/django-leaflet#...

mattmcc, oh, cool

mostly concerned with the admin right now but that'S definitely good to know