Re: Results of testing votizen's py2.6/7 codebase against django master (319e1355190)

2012-09-18 Thread Jeremy Dunck 
On Tue, Sep 18, 2012 at 11:23 AM, Jeremy Dunck  wrote:
...
> And the last one, I hesitate to raise because it's likely to be
> specific to my machine, but... our (django-nose-based) test runner
> hangs after completing the suite but before tearing down.  Using
> dtruss I can see it's hanging on select/kevent, and using gdb I see
> it's in _mysql_ConnectionObject_query.  I'm unsure where to get debug
> symbols for either mac python or mysqldb (or at least, I haven't spent
> the time to get there).  I mention it despite it seeming
> environment-specific because it's possibly hanging due to the
> unicode/py3 changes.  I just don't know.
>
> #0  0x7fff9867aaf2 in read ()
> #1  0x0001105fe8ba in vio_read ()
> #2  0x00011057fbb1 in my_real_read ()
> #3  0x00011057f778 in my_net_read ()
> #4  0x000110572cb2 in cli_safe_read ()
> #5  0x00011057705d in cli_read_query_result ()
> #6  0x00011057608e in mysql_real_query ()
> #7  0x000110563d14 in _mysql_ConnectionObject_query ()
> #8  0x00010f738d77 in PyEval_EvalFrameEx ()

Florian and Anssi helped troubleshoot this -
https://code.djangoproject.com/ticket/18984

I am using multi-db with some TEST_MIRROR'd aliases, each of which has
a pending transaction.  The flush at the end of TestCase locks forever
waiting for a table lock, essentially deadlocking.  Rolling back
pending transactions just before flush releases the related locks.

I consider this a release blocker because many multidb apps would
likely hit this.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Results of testing votizen's py2.6/7 codebase against django master (319e1355190)

2012-09-18 Thread Jeremy Dunck 
In response to the call to test py2.x on django's current master, I
ran the test suite for Votizen.  Our codebase is currently running
with django 1.4.x.

Our codebase is ~100kloc, ~32kloc of which is tests.  We use abstract
model inheritance a good bit, but no concrete inheritance.  No i18n or
multi-tz.

In use:
  python2.6/2.7
  python-memcache
  tastypie
  MySQLdb
  django-celery/celery
  django-imagekit
  django-classy-tags

Results (so far):
  1) Our custom test runner broke: we used to force DB connection
feature detection (there was a bug in TEST_MIRROR'd feature detection)
so we could do some juggling; forced detection is now gone and is
implicit; this seems to remove the need to even do the underlying hack
for us.

  2) Revealed a DB alias which was missing a TEST_MIRROR declaration
for us.  It used to work, but we were wrong and just lucky.

  3) tastypie broken by a const moving in the django tree; fixed in
https://github.com/toastdriven/django-tastypie/commit/71a1f0a161a7f3d549bce9b07984212ee4a8c81a

  4) after upgrading tastypie master
(27d17b7db7afd6c81da24f64f5b4562b59134582), a bunch of failures like:
...
return self.dispatch('list', request, **kwargs)
  vi +176  upvote/api/tastypie.py  # dispatch
response = self._dispatch(request_type, request, **kwargs)
...
  vi +172  upvote/api/tastypie.py  # _dispatch
request, **kwargs)
  vi +474  
/Users/jdunck/.virtualenvs/votizen-1.5/lib/python2.7/site-packages/tastypie/resources.py
 # dispatch
response = method(request, **kwargs)
  vi +1130 
/Users/jdunck/.virtualenvs/votizen-1.5/lib/python2.7/site-packages/tastypie/resources.py
 # get_list
paginator = self._meta.paginator_class(request.GET,
sorted_objects, resource_uri=self.get_resource_uri(),
limit=self._meta.limit, max_limit=self._meta.max_limit,
collection_name=self._meta.collection_name)
TypeError: get_resource_uri() takes exactly 2 arguments (1 given)

-- it turns out our subclass .get_resource_uri *required*
bundle_or_obj, while tastypie internally does bundle_or_obj=None.  It
happened to work on 0.9.11; switching ours to also be optional fixed.

  5) We have some URLNode subclasses and as such had to have a
compatibility layer for future.url and furture.URLNode moving to
django.template.

  6) We had some test failures where
TransactionalTestCase.assertContains used to work (text was coerced by
smart_str prior to d1452f60974da6f0e54ff9ad7a03d2c115675d10).  While
we could argue that only text vars should be passed to
assert(Not)Contains, I think the removal of smart_str(text) here was
likely unintentional.  Post-py3ization, I think it should probably be
put back as force_text(text, response._charset).
I raised a ticket and made a related patch/pull req:
https://code.djangoproject.com/ticket/18980


I have a couple remaining issues which I've run out of time to work
through just now:

upvote.api.tests.test_tastypie:VoterResourceTestCase.test_X
ValueError: astimezone() cannot be applied to a naive datetime
(tastypie master + dj 1.5?)

upvote.candidates.tests.views.test_profile_home:CandidatesProfileTest.test_friends
EmptyPage: That page contains no results
(almost certainly an internal problem)

And the last one, I hesitate to raise because it's likely to be
specific to my machine, but... our (django-nose-based) test runner
hangs after completing the suite but before tearing down.  Using
dtruss I can see it's hanging on select/kevent, and using gdb I see
it's in _mysql_ConnectionObject_query.  I'm unsure where to get debug
symbols for either mac python or mysqldb (or at least, I haven't spent
the time to get there).  I mention it despite it seeming
environment-specific because it's possibly hanging due to the
unicode/py3 changes.  I just don't know.

#0  0x7fff9867aaf2 in read ()
#1  0x0001105fe8ba in vio_read ()
#2  0x00011057fbb1 in my_real_read ()
#3  0x00011057f778 in my_net_read ()
#4  0x000110572cb2 in cli_safe_read ()
#5  0x00011057705d in cli_read_query_result ()
#6  0x00011057608e in mysql_real_query ()
#7  0x000110563d14 in _mysql_ConnectionObject_query ()
#8  0x00010f738d77 in PyEval_EvalFrameEx ()

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.