DjangoBot: #django-dev

anybody knows in which timezone is Sausalito with respect to UTC?

timeanddate.com doesn't seem to be of help

cramm: well it's 5:41pm :)

salkot: ok, it' UTC-9 then. Thanks!

salkot: taht would be which USA domestic timezone?

sorry, it's UTC-7

pacific time

PDT, right?

yes, i think so

k, done

timeanddate.com is your friend. ;)

hrm

we're less than 150 tickets away from catching up with commit numbers

Shame we can't just recycle tickets that were spam.

and commits that will be undone *ahem*oldforms*ahem*

Gulopine: funny because I often look at that metric, although meaningless.

yeah, it's really rather a useless observation

but still, i've been paying attention, wondering when they'd converge

finally found what was causing another test failure

it was caused by something i put in to satisfy other tests, and for backwards compatibility :(

Has anyone done any recent work on an object cache? I know #5514 with the goal of single-instances in memory was closed, but I'm having a serious problem with duplicated queries, and caching the results won't fully solve the problem since the page I need to generate is needs a short cache timeout.

In particular: len(set([q['sql'] for q in connection.queries])) == 427. len(connection.queries) == 5643

I would love for something like this to be able to be turned on via a setting MODEL_CACHE_VERSION = True in django core. http://dpaste.com/65873/

thoughts?

with that as a base, it would be possible to cache all fkey lookups without having to worry about cache invalidation because of the model revision number

the corresponding piece of this would go into the ReverseSingleRelatedObjectDescriptor -- instead of doing a sql query if the object has not been cached on the instance, it would do a memcached lookup first for the object, and only then if the object didn't exist, it would do the sql query.

j #django-sprint

er

I did a proof of concept implmentation on only the forward relation (singlerelatedobjectdescriptor) and it dropped the number of queries required from 5643 to 1977 for my problem page

Gulopine: Hop in #django-sprint :P

jbronn: Hi. Do you have a couple of minutes?

cramm: sure

jbronn: it's about the Oracle abckend. Do you run the test suite using it often?

not really, I can on request; I don't think that pickling bug has been fixed

I suspect r7885 (and its followup 7901) may affect the way Ocale detects the need of custom limit+offset handling

oh yes, the pickling thing is still there

cramm: on first glance, I doubt the pagination in Oracle is affected; `OracleQuery` has it's own `as_sql` that's overloaded

jbronn: eys I know but, as I understand, now None is the value used to indicate no upper bound limit and that may affect this test?: http://code.djangoproject.com/browser/django/tr...

jbronn: there is a very big possibility I'm totally wrong but as there is no buildbot slave running against Oracle...

cramm: bool(None) == bool(0); but I run the GeoDjango tests against Oracle regularly, and those wouldn't work if pagination was broken so I'll check it out on my next merge

oh ok I was thinking things could break when using something like queryset_instance[:0]

now for the second qeustion? I might be able to adapt a debian system with 1GiB of RAM so I can install oracle xe on it and was wondering how much memory do you dedicate to your Oracle environment VM

so maybe I can stop bothering you with these Oracle-related questions :)

cramm: I run Oracle (10.2 full version) on Windows, and I think the VM has 772MB.

now it's entirely possible that corner-case bug exists on Oracle, but I don't think pagination is broken

jbronn: Ok. Thank you very much for your time and patience

brosner: you available? i've found a pretty weird bug in nfa

hehe what is nfa?

no longer exists

haha

what once was nfa

it is now in trunk :)

r7967

hah, that's awesome

cool

you get it in trunk for 30 seconds and somebody finds a bug :)

lol

brosner: "This is a backward incompatible change." hahahaha

basically, if you have a onetoone field pointing at the User model, the list_filter interface on the user list disappears

nice work everyone

:)

if you change that onetoone field to a FK it comes back

So we're going to have a shitton of "the admin doesn't work OMG!!!!" errors

er, bug reports

does the old one even work at all?

so keep an eye out