DjangoBot: #django-dev

just need to do it right, which i haven't spent time on

Oh, I read this as being how doc/ is hard coded, not root_path itself

yeah check each documentation view and see their root_path calculation

i think you will see immediately how to fix it

Ok, I see, sorry that was dumb

:)

The solution is to use the URLconf as I've suggested :D

#6470 ;)

hey Gulopine, awesome patch!

I'm updating S3Storage right now, do you have some time?

a little time, yeah

i have to leave for work in about 25 minutes

how's it working out for you?

ok, in File._get_size() it seems that you don't look at storage.size ?

or maybe I miss something

but when I try obj1.normal.size, it raises an error

hrm, no, you're right

i had started making a StorageFile that would stash a reference to the storage system, but i pulled it out

i wasn't sure how best to do it and make it useful as a base for all backends

i think our best bet would be to have the backend provide a File subclass directly

ok, another issue with storages and open(), for the moment open() is located in FileSystemStorage, I propose to move it to Storage or maybe I should inherit from FileSystemStorage?

otherwise you can't just define _open()

!

damn, you're right :(

cause no, you shouldn't have to subclass FileSystemStorage, that's just asking for problems :)

yes :)

about backend providing a File subclass, how do you thing it should be done?

you can move it in your local copy, so you can keep going, but i'm updating the patch too

ok, that's what I had done

you should be able to just override __init__, size, those kinds of things as you need, then return an instance of that from _open()

but if you think it'd be easier to come up with a StorageFile, that's cool too

i just thought with the whole acts-like-a-file thing, that it'd be easier for the backend to provide a more customized File that accesses the backend directly, rather than having to blindly pass through to self.storage

i was thinking that'd get really tough to do generically when you have to allow multiple calls to .read(), for instance

ok I understand and I agree

I'll subclass RemoteFile

let me know how that works out, i'm getting more and more hesitant about subclassing StringIO

when using cStringIO, it doesn't behave exactly like a standard class, so things might get tricky

i suppose it'd be easy enough to provide a mostly-there StorageFile, covering things like size and url, but not open(), read(), write() and close()

leaving things like chunked reads and optional buffered writes up to the backend

ok

the one-off features (size, url, etc) are easy enough to add on a base class and have them Just Work

i'll get to work on updating that tonight

i gotta head off to work now though

Hi, s validators_list actually working?

jacobkm: might be time to update the "When will you release Django 1.0?" FAQ :)

gdoubleu_: probably yeah, but not today I don't think.

gdoubleu_: can you open a ticket so I don't forget?

jacobkm: sure thing

On Friday, I coded up an implementation of a single related object descriptor cache that versions model classes and achieved a huge performance boost on my app. I'd like to give the code back, but I'm not sure if it's in a form that would be generally usable for the community at large.

There are two components: 1. a set of signals on post_delete and post_save to increment a memcache key for a given model class (version number).

2. A lookup in the singlerelatedobjectdescriptor class and reversesinglerelatedobjectdescriptor that references the class version and primary key to reduce repeated queries for the same objects.

since the version number is incremented on every save and delete, the cache will never be stale.

jhenry: sounds neat.

jacobkm: re: last call for the alpha: Are the handgul of tickets marked as 2070-fix worth being considered before it's tagged?

*handful

Given the dependence on a fast and large automatically-invalidating cache (memcached), I'm not quite sure how best to integrate it. It could certainly be enabled by a settings switch.

cramm: I'll take a look, but I think they're OK to be fixed in the next weeks... the alpha's really a snapshot release made to force us to get certain things done in certain order.

ok, np. Just wanted to be sure I raised the issue just in case

we are using django svn and we get lots of duplicate entry bugs and editing isn't always possible, because django executes an INSERT instead of an UPDATE

is this bug already known?

tux21b: you may want to search for it in Django Trac and open a ticket if you don't find it already reported, together with a minimal test case that shows it's really a Django bug and details about database backend, etc.

cramm, i am quite busy now, but i will do it. its urgent :)

tux21b: without any further information it is impossible to judge whether you found a bug in Django, or a bug in your own code.

hmm... even "a = Article.objects.get(id=5); a.save()" executes an insert. pk is set here, mysql is the backend and save_base() or Model.save(a) doesn't work either

and i get it in nearly every django model

(but not with every instance...)

And have you overridden save() on these models?

yes, some are overridden and others are not. and even Model.save and save_base doesn't work

Do you have any custom managers on these models?

just this, i think that can't be the reason: http://paste.pocoo.org/show/79990/

and the bug isn't there that long, but i can't tell you the time, because we aren't updating all the time

is there something i should try? i still have the python shell open and can reproduce the step

Erm.

There are some potential issues there.

Any time you set up a default manager which filters the initial QuerySet, you raise the possibility that things which rely on the default manager (e.g., base_save() will screw up.

So it's quite possible that at the time save() is called, the default manager doesn't find the record in the DB and so thinks it needs to INSERT.

ok, sounds logically. i will give it a try without the manager and report :)

Also, your manager tries to do a lookup type of 'qt'.

It probably wants to do 'gt' instead.

qt?

ah, ok

first i try without one...

ubernostrum, ok. the bug is related to our manager. with out one it works... so i am really sorry for that

but i still don't really understand why

we have this source, so objects doesn't filter anything: http://paste.pocoo.org/show/79991/

ok problem solved. if you are interested, the ordering of the definitions matters. so, objects must be the first manager defined in Article

tux21b: just as documented (last paragraph) :) http://www.djangoproject.com/documentation/mode...

oh, i feel realy awful about it... sorry. but many thanks anyway :)

Here's the code to make the related object descriptor cache work: http://dpaste.com/66477/

Are there any major changes in implementation that would have to happen in order for that to be a generally-usable piece of code?

is #6755 anywhere near completion?

i want to start on moving my userprofile to use model inheritance, but only if i know i'll be able to test it on the admin site tonight