DjangoBot: #django-dev

was there ever a models.OrderingField?

django_sqlalchemy is attempting to make use of that field and it doesn't appear to be valid

hahahah

yeah, there was

has been droipped or replaced with something else? i was going to patch django_sqlalchemy

i think it was dropped

if i recall, it was leftover from the way things used to work, and was no longer used in core

and i guess nobody spoke up about it before it got removed

thanks

I think it was originally added for magic-removal

so sayeth the link :)

paltman: yeah I had to implement it because django did.

but it made no sense at the time.

so good ridance

paltman: I will update the dj-sa code or if you want to make the change in your clone go ahead and I can pull it.

i am trying to get your gitalicious project running, but am having trouble with dj-al

is it in a runnable state

paltman: not going to work :)

or is it still under dev?

ahh

ok

wasn't sure

the gitalicious code was developed under dj-sa before class replacement.

now dj-sa support class replacement so I have to update gitalicious.

is that your main objective?

yeah

i mean

paltman: let me priv msg you

my main objective is getting gitialicious running internally

since this is not django related

sure

hey axiak, another minor style question for you if you have a minute

dutr

sure*

oh! hey

is there a particular reason you went with "raw_field" as the name of the input to _save_FIELD_file()?

seems like an odd choice

yeah it might be a little odd

i have to move all that anyway, and i was thinking about just calling it "content"

but i wanted your input, in case there was a reason for that name

well it's just that sometimes it's not only the content, and the actual object

well yeah, but i'd argue that the object is content too

auto_now and auto_now_add are going to be removed eventually, right?

that's why i'm chaning it away from "raw_content"

alex, i believe so

ok

So they should probably be tossing up a DeprecationWarning

axiak, i just don't know what it's raw_field, since it's not a field at all

yup

alex, i would think so, but i don't know why it hasn't been this whole time

Ok, I'll post a ticket

good call

cause yeah, in my mind, those should issue DeprecationWarning and get pulled straight out for 1.0

If I just stick raise DeprecationWarning("auto_now and auto_now_add are deprecated"), they will still work, just raise the erorr, or do I need to import warning and do warning.warn() ?

they still work? that seems odd to me, but i've never tried raising DeprecationWarning

or are you asking if they'd still work?

cause i would think it would cause them to break

Askiing

ah

i think you have to import warnings

Ok

ah crap, i gotta update the tests to use SimpleUploadedFile or something too

hrm, never got around to seeing if i can combine the apis for that and File

you can't raise DeprecationWarning

ah, okay then, that settles it :)

do warning.warn, ok, thanks

example:

warnings.warn( message = "To access the file size, please use the .size attribute.", category = DeprecationWarning, stacklevel = 2)

it changes the line number and function reporting

so depending on where it is, it allows the warning to display information about the user's code

really

like, showing the line number of where they actually called the wrong thing?

rather than just where the warning was thrown?

yeah

nice

yup, like a stack rollback.

holy carpoh boy

whoops :)

two separate thoughts there, meant to delete the first one

uh oh

so axiak, there are now *two* UploadedFiles?

:)

that's actually fixed in a patch

ah, okay

it cleans up a lot

i guess i need to start looking at that one

I think jacobkm will apply that soon

he said it was high priority for him

i just tried debugging tests, and i get "'UploadedFile' object has no attribute 'content'" and i realized i didn't know which one it is :)

yeah

if you want I can rename raw_field in that patch as well :)

it'd certainly make me feel less bad about doing it in mine :)

but with all that, i think it's better for me to just wait until that hits trunk

on trying to merge this stuff i mean

cause it'll be just as hard to merge in that patch again once it lands, and i'd rather do he work just once

yeah

k, back to the book

axiak: Firefox, the dev server and firefox on apache with mod_python

Firefox 3

lakin: hey

yo

odd

that's my default test setup exactly :)

so right now I'm in /admin/myapp/file/add/

(where file is your File model)

Yeah. Strange, I started from a completely clean app, and I can't reproduce it now either.

heh, that's bad

yeah

hrmm

you never used any other browser?

did you say you uploaded no file, or an empty file?

no file

The file was already there

oh, okay

let me try that

I just hit save and continue editing again

It's a very large file

well, not huge

I can reproduce it exactly with my current setup

interesting

this code is invalid

__unicode__() returns self.filename()

yeah, sorry

I was trying to give you a minimal test case and I forgot that line

self.filename just returns a string

okay

here's a clue

just try not to make too many changes

I had a middleware in my setup that re-creates it.

okay

it was when my middleware tried to access the request.POST

interesting

give me a few minutes, see if I can reproduce it with a more minimal example

okay, cool

hrmm

just adding the middleware in didn't get it

hmm

aaah, it's based on the POST data

okay, how so?

I don't know exactly, but copying the data I had in my database to the clean install reproduced it.

I'm cleaning up a bit and then I'll give you a tarball

ok

axiak: http://lakin.weckers.net/static/django/testbed....

ok

oops

what's wrong?

I think the settings file may not be picking up the right database

hmm

yeah, that was it

just set the DATABASE_NAME appropriately

There are two files in the db, I've tried saving both and get the error.

do you need to send me another tar, or can I make the change to the settings.py file?

ok

make the change

my bad for being so flakey, I'm a bit tired. :)

it's okay

swim.website.models? :)

hmm

PathField?

argh

change it to CharField

AutoFileField too?

or I can remove all of that if you'd prefer

FileField

okay

just checking

yeah, no worries

btw, that data isn't public, so I'm going to take that tarball down now

So if we can somehow make a better test case before putting on the bug report, I'd appreciate it.

yeah

btw, you have a username pass :)

i'll just set one

heh

sa/something :)

yup

I wasn't expecting to have to send a database with the bug report. :/

good thing there's a set_password() :)

yup

and manage.py shell

ding ding ding

we got something

okay

so you repro'd it?

yep

ok.

this is great

now I have the raw request

everything is good now :)

cool

hahaha

I found it :)

lakin: so I found the issue

ok, cool.

I just posted an explanation

ok, that makes sense.

yup

yeah

so what do you think of 100k? :)

actually, I can do that quite easily. :)

well you don't need to

you can just create a request

especially if it's a django api or something

Yeah, I can create one in the admin in my app pretty easily

the 'number of codes to create' creates that many related codes

well it's more than just the admin

yeah, I was just curious what FF would do

oh

So, back to the real issue.

so yeah

a piece of me wants to remove the check

since it's survived a lot of development

raising it would definitely solve the immediate problem and wouldn't likely be hit by most people.

and afaik we haven't hit that infinite loop

What does django set for it's recursion depth?

it's not recursion though

yeah

but what are you talking about? python has its own checks right?

for recursion? yes.

does django have its own limit I"m not aware of?

Not that I know of

ok :)

just confused

So the only reason it was put in originally was to deal with some infinite loops that were showing up?

once a long long time ago

Ideally, we'd like to raise an appropriate error if ever another infinite loop shows up

and we decided that we never wanted to see that error

yeah

so maybe something even, like 64k? ;0

It's gets incremented for each form field?

yeah

I'll look to see if there's any better place to count

hmm

though I don't think there is

sigh

Well, the main issue is to avoid a DoS if someone submits an extremely large POSt

right?

you mean the reason for all of this?

yeah/

yeah

stream the data, rather than loading it all into memory

right. But it's also a matter of how much data will we accept in one request?

no, that's better dealt with at the apache/lighttpd level

like, it gives you the ability to if you so chose

but I didn't put that in as a setting or anything

Yeah, I was thinking of a setting.

yeah...I think that's false security

it's a poor way of dealing with it

having a setting for it is?

doing it in the django side

I'm not sure I agree tho. Of course, it's probably more secure and stable to deal with request-size issues at the apache/lightty level, but it's definitely a convenience to do it at the django level too.

yeah but it's not like the solution is optimal

like

the result is poor

lakin: at the django point you have to already load the file into memory

either django soaks up cpu time reading in the network

or you cause a connection reset error

connection reset error?

yeah

Why not return an invalid request header or something?

:)

wouldn't that be nice.

the problem is, there's no way to tell apache/lighttpd/etc during the request: "Hey, tell the client to stop giving data and return this data"

so you have to options:

Oh ...

1) Read everything and do nothing with it and return the error

2) Force a connection reset error

In that case, taking the check out doesn't bother me.

or secret option number 3: let apache/lighttpd deal with it :)

I keep forgetting that django doesn't come with an built-in production ready webserver. Been doing too much work in CherryPy lately. ;)

:P

btw, there is a small bug in there, if you unget bytes, _modifications_since is incremented, shouldn't it also be decremented?

maybe not

absolutely not

one of the inifinte loop bugs was ungetting and getting repetatively :)

repeatatively*

aaah, that's why you started counting _modifications_since

Well, thanks for tracking it down

thanks for being such a good bug reporter :)

the patch is on trac, if malcolm is feeling risky he'll apply it otherwise jacob will get to it

heh

alright, I need to sleep

good night!

hi :-) i've got a few logic-questions regarding the new upload handler esp. the memory handler if i may. shouldn't it somehow not just rely on the content-length header? something like throwing an exception within receive_data_chunk the moment the indicated content-length is passed?

noone llooks at #6587 , /me bored want work ;)

grah! anybody got experience with the oracle backend?

not necessarily with using it, but how the query stuff is set up for it