#django

What is the actual harm that comes out of running a test suite on the production server...?

As long as you back up your production DB beforehand

leo-the-manic: there's likely no *harm*, but that's not the point

leo-the-manic: what's the *harm* in doing design work in JS? what's the *harm* in handling all of your data validation in views instead of forms?

leo-the-manic: both of those things work. they're just not the correct way to do them

mlavin: the point is not that the default name is random. the point is that the database user cannot create databases with names matching the defaults.

As to whether some of you think this is not a good practice, well, don't do it then. :-)

Mathium leo-the-manic: the tests use a separate DB but you could accidentally pollute your production cache data, file system (i.e. MEDIA_ROOT), task queue, search index, etc. Not to mention that running the tests takes system resources (CPU, memory, DB connections) away from running the production site.

mlavin: sure, which is why I'm running my tests on my production server but using a different database and a different virtual host and a different directory structure for static and media and friends.

I am not sitting in the production directory of the production server and running 'manage.py test'.

I have 'foo_barprod' and 'foo_bardev' and 'foo_bartest'. I just can't have 'test_foo_barprod' as Django would use for default.

As for taking system resources, I'm on a shared host so that's obviously not a major concern.

mlavin: So then how do you keep the production and dev/staging environments perfectly synced? VMs?

mlavin: why do they need to be synced? build them with similar resources with the same packages. done

__love__: that works if you're running on systems you totally control.

__love__: But if you deploy and it turns out your production server has some subtle configuration error, when do you find out? After you deploy and the site doesn't work?

That's not the case with me, as I mentioned from the start.

__love__: Esp. when upgrading packages

Mathuin: you don't totally control your local box? set up a VM and be done with it

when updating a model.. do I check for permission in the models.py and pass the user .. or checkin the view?

leo-the-manic: if they're configured the same...

Mmm.

eraldo: permissions checks belong in the view

the model has an owner

leo-the-manic: automated provisioning and deployments keeps them in sync though we are talking about running the test suite which isn't quite the same thing

eraldo: no, the model has an FK to a user instance. the view has a user who may or may not be that FK

is there an easy way to add a line break to a form error message? (i.e. inside 'msg' in self.error_class([msg])

Oh... so they *are* kept in sync then

Guess I misunderstood

__love__: so checking if the user may change the status of the model happens in the view not in the set_status method of the model

eraldo: that would be my approach, yes. your data doesn't care who created/modified it. your workflow does

well.. in the set_status I also put other checks ..like if new_status == old_status: do_something()

eraldo: sure, but that's data validity, not flow control/permissions

I thought since the model also has an owner FK it might also belong there.. but okay.. thanks for telling me. :)

eraldo: you can do it in the model. it just requires you to pass in the user every time

eraldo: seems like extra, needless work to me

What's the easiest way to create a datetime.datetime object with hours=minutes=seconds=microseconds=0 ?

Anyone here understands Haystack perfectly? Their channel as no activity what so ever and I am kind of confused lol

leo-the-manic: I'm not sure where your sync comment was coming from. my point is that for example if you are running `manage.py test` on the production host and your cache settings are the same as the production site (say local memcache) then running the tests will put bad data into your production cache. there are a number of settings which can have the same issue.

b0rsuk: datetime(0,0,0,0,0,0,0)

mlavin: Yeah, I followed that and understand. My response was how to detect errors in the production config? Using a VM? How do you keep staging and production environments the same?

leo-the-manic: you don't change one unless you change the other

abisson: you try the mailing list?

leo-the-manic: gotcha. yes that is avoided by automation (Fabric, Chef, Puppet, Salt, <pick your favorite>)

mlavin: __love__ asked why they would need to be the same, then you claimed they stay in sync, so I was confused and then less confused

v0lksman: ...and now with current date ? datetime.datetime(utcnow().year, utcnow().month, utcnow().day, 0, 0, 0) ?

__love__: well my model is more complex than that.. there is an owner "fk-user" a list of members "fk-users" and more.. so I thought about just calling model.has_permission(request.user, 'action') and react upon the true or false return

NomadJim: posted a while ago, never got an anwser

abisson: how long is a while

38 hours?

I wish I could do something like datetime.datetime(0, 0, 0, 0, 0, 0, 0).replace(date=datetime.date.today())

abisson: I wanted to use haystack, kinda sad to hear

;(

question : I'm trying to set a cookie independently of the session (persistent cookie), I'm currently thinking of adding a middleware layer - is this the best way to go about this?

NomadJim: well it's good, I am just confused regarding some stuff lol

eraldo: you certainly can. but i'd do that in the view. a) the user is native to the view; and b) you're closer to the request/response in the view which is where you'd send errors

NomadJim: Possibly forever. Until the condition is no longer true.

b0rsuk: a replace that took a datetime and a date shouldn't be hard

you so silly

__love__: true.. thanks for giving me the reasons.. now I understand it better. :)

abisson: what part of Haystack are you confused about?

mlavin: ok so I have this: https://dpaste.de/307bv/ Now let's say I want to access the manufacturer's name when I get my EquipmentModel's results. I will get it by doing results.object.manufacturer.name. That is fine, I get that.

Now, should I put manufacturer as an index or not? It seems like text is all I need.

guys if you still aware of my problem ! when type my domain/django I receive error 404, but different from the one when I type non existing folder domain/xxdff. does that means that I at least have some response from the wsgi ?

for those here not using template system - instead using static html and modifying it with js - what build system are you using - tempalte system?

abisson: it would be a best practice to include everything you need to render on the result. see http://django-haystack.readthedocs.org/en/lates...

mlavin: ok so basically, what is in the SearchIndex, should be the fields I want to return from the search, or fields I allow search on?

That's the part I am confused. Where do I define the fields I allow search on, and where do I define the fields I want to return?

mlavin: That is basically my confusion

guys I want to use django with wsgi on apache and cpanel, I installed the wsgi and pointed the alias to my django project, but it does not work - I receive error 404, did I miss something ?

abisson: the fields you can search on are defined on EquipmentModelIndex. right now you only have a text field. you can store additional fields which are not searchable by using indexed=False

tried 128 channels and no one can help me. what is this

mlavin: so basically, the fields I store should be the ones that are returned by the SearchQuerySet correct?

abisson: yes the fields you store will be available when you are accessing/rendering a result from a SearchQuerySet and you will not have to hit the Django DB to access them.

toli. sounds like your apache httpd.conf to me

hey django

tbaxter: I did whatever django deployment docs says

mlavin: ok, so if I have this then: https://dpaste.de/mKmmD/ I should only have the name of the Model, and the name of the Manufacturer?

django deployment docs aren't going to tell you how to configure a site in your apache conf

stored in Haystack

tbaxter: yes: WSGIScriptAlias /django /home/iget/public_html/django/webapp/webapp/wsgi.py

tbaxter: I read this on the website :) of django

But let me ask this… what 404 are you getting, the standard apache 404?

tbaxter: it says internal server error 404

I'm saying this doesn't sound like a django or wsgi problem. It sounds like your apache conf is wrong.

tbaxter: I think it is the apache yes

I'm having some trouble with my log's permissions when I try to run 'collectstatic' through a git hook script, but only when the script is triggered by git and not when I run the script directly on the server.

tbaxter: yes probably yes

Yeah, I get that.. my question is, is it the standard apache 404

tbaxter: I think so

abisson: it will also store the object pk. I'm not sure about any other additional meta data

mlavin: alright! good thanks :)

tbaxter: check iget.be/django is the one with my project and check other one like iget.be/blabla

tbaxter: it's the standard apache

error

then it definitely sounds like apache conf. You're not getting even hitting wsgi or django, I think.