Re: Complicated, strange bug in ``prefetch_related`` when used in the context of a test client

[Anssi Kääriäinen]

On 29 loka, 06:05, Yo-Yo Ma  wrote:
> I'm still working on forming some sort of understanding of what exactly
> causes this and/or what is even going on, so any help is much appreciated.

Based on this bug report there is no way to help. We don't have the
models, or how the results are different. This part looks especially
suspicious:

> queryset = Foo.objects.all()
> queryset = queryset.prefetch_related('bars__baz')
> obj = queryset.get(pk=1)
>
> are different from the results of:
>
> obj = Foo.objects.all().prefetch_related('bars__baz').get(pk=1)

The queries are identical. Only possibility is that there is something
really, really strange going on with the garbage collector. I don't
recall us defining any __del__ methods which could cause anything
serious, so it seems that if there is actually a bug here, it means
the bug is in Python. Actually, I am not sure of the semantics of
Python's garbage collector, it might be that the two above queries are
_exactly_ identical in Python.

My wild guesses:
  - some sort of state leak in testing
  - non-deterministic bug in prefetch_related (likely caused by random
ordering of the rows in the resultset)

I hope you can provide us more data about this situation,
 - Anssi

-- 
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.

Re: Github tags

[Jan Bednařík]

There is also related ticket https://code.djangoproject.com/ticket/19141

Jan


On Mon, Oct 29, 2012 at 3:36 AM, Matt Austin  wrote:
> Hi,
>
> Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5
> alpha tagged on the github repository? The tagging seems to have
> fallen behind with these releases.
>
> Thanks,
>
> --
> Matt
>
> --
> 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.
>

-- 
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.

Re: How to test patch

[Marko Tibold]

Hi all, 

I can really recommend travis. We use it for testing Django REST Framework. 
The config can be as simple as 
this 
https://github.com/tomchristie/django-rest-framework/blob/restframework2/.travis.yml

The availability of the travis service is not 100 %, this is mainly due to 
the very large amount of OSS projects (5000+) that rely on the service. But 
whenever downtime occurs, the problems tend be solved quickly and status 
reports are sent via twitter.

Marko

On Sunday, October 28, 2012 4:57:01 PM UTC+1, dstufft wrote:
>
>  Travis or Jenkins can be setup to test PR's and use Github's API to mark 
> the PR as good to merge or not. 
>
> On Sunday, October 28, 2012 at 5:20 AM, Russell Keith-Magee wrote:
>
>
> On Sun, Oct 28, 2012 at 3:55 PM, Dominic Rodger 
> 
> > wrote:
>
> Another long time user here (at some point I'd love to make the jump to 
> contributor, just need to find more time) - out of interest, is there a 
> reason we don't use Travis? I wonder if that might help those with commit 
> access, since pre-tested pull requests would mean you could have confidence 
> that the tests at least pass. Apologies if this has been discussed before 
> (there are a few contributors to this group called Travis, which made 
> searching a bit tricky!).
>
>
> We do have a CI server (a Jenkins install) - you can find it here:
>
> http://ci.django-cms.org/job/Django/
>
> We don't currently test every fork or pull request on GitHub, but that's 
> certainly an interesting idea, especially if we could get validation that a 
> pull request passes the full test suite.
>
> I haven't spent any time messing around with Travis configuration to know 
> how hard this would be to set up -- and whether the build failures can be 
> communicated in an effective way. If you're looking for a way to 
> contribute, investigating the options here might be an interesting place to 
> start.
>
> Yours,
> Russ Magee %-)
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com
> .
> To unsubscribe from this group, send email to 
> django-develop...@googlegroups.com .
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>  
>
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/ddqnV4W690IJ.
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.

Re: How to test patch

[Aymeric Augustin]

We tried moving Django's CI to Travis about 6 months ago. Unfortunately,
Travis' time limit is too low for Django's test suite. We contacted them,
but as of August 6th, we were still waiting for them to increase the limit.
I haven't had any news since then.

Over the last months I've had mixed feedback about Travis and I'm less
enthusiastic than I used to be. The tendency to report failures of their
infrastructure as failed tests is annoying. The .travis.yml format is
simple but it's often difficult to make the builds run. I've seen many
people making series of commits, blindly attempting to make their code
importable, and not always succeeding. If Django uses a service, it's a
strong signal for the community; I can't say I'm ready to give this signal
right now for Travis.

Jenkins isn't perfect and it's painful to maintain. But it does the job and
makes it easy for us to run experiments (eg. pypy, Oracle) or diagnose
failures. We don't have short- or medium-terms plans to stop using Jenkins.

Finally, I'd like to thank Divio AG  for funding the
server that hosts ci.djangoproject.com.

-- 
Aymeric.


2012/10/29 Marko Tibold 

> Hi all,
>
> I can really recommend travis. We use it for testing Django REST
> Framework. The config can be as simple as this
> https://github.com/tomchristie/django-rest-framework/blob/restframework2/.travis.yml
>
> The availability of the travis service is not 100 %, this is mainly due to
> the very large amount of OSS projects (5000+) that rely on the service. But
> whenever downtime occurs, the problems tend be solved quickly and status
> reports are sent via twitter.
>
> Marko
>
> On Sunday, October 28, 2012 4:57:01 PM UTC+1, dstufft wrote:
>
>>  Travis or Jenkins can be setup to test PR's and use Github's API to
>> mark the PR as good to merge or not.
>>
>> On Sunday, October 28, 2012 at 5:20 AM, Russell Keith-Magee wrote:
>>
>>
>> On Sun, Oct 28, 2012 at 3:55 PM, Dominic Rodger wrote:
>>
>> Another long time user here (at some point I'd love to make the jump to
>> contributor, just need to find more time) - out of interest, is there a
>> reason we don't use Travis? I wonder if that might help those with commit
>> access, since pre-tested pull requests would mean you could have confidence
>> that the tests at least pass. Apologies if this has been discussed before
>> (there are a few contributors to this group called Travis, which made
>> searching a bit tricky!).
>>
>>
>> We do have a CI server (a Jenkins install) - you can find it here:
>>
>> http://ci.django-cms.org/job/**Django/
>>
>> We don't currently test every fork or pull request on GitHub, but that's
>> certainly an interesting idea, especially if we could get validation that a
>> pull request passes the full test suite.
>>
>> I haven't spent any time messing around with Travis configuration to know
>> how hard this would be to set up -- and whether the build failures can be
>> communicated in an effective way. If you're looking for a way to
>> contribute, investigating the options here might be an interesting place to
>> start.
>>
>> Yours,
>> Russ Magee %-)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-d...@**googlegroups.com.
>> To unsubscribe from this group, send email to django-develop...@**
>> googlegroups.com.
>>
>> For more options, visit this group at http://groups.google.com/**
>> group/django-developers?hl=en
>> .
>>
>>
>>   --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/ddqnV4W690IJ.
>
> 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.
>

-- 
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.

Single table inheritance - working implementation

[Krzysztof Jurewicz]

Hi all,

In February, Craig de Stigter released 
django-typed-models,
 
a package implementing inheritance hierarchy for Proxy models with 
automatic type recasting. I've written a fork of it with additional 
possibility of adding fields to subclasses, therefore achieving a single 
table inheritance implementation similar to Ruby on Rails' STI. This is 
possible mostly thanks to metaclass magic and monkey patching.

The fork's homepage is at https://github.com/KrzysiekJ/django-typed-models. 
Note that it should be considered early alpha and there is much room for 
optimisation, code cleanup and maybe additional features. Feel free to fork 
and/or add issues.

I don't know yet what to do with licensing since Craig didn't specify any 
license in the original package. Craig, please comment or send me an email.

Regards,
Krzysztof Jurewicz

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/aSgkQliZHtYJ.
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.

Re: Complicated, strange bug in ``prefetch_related`` when used in the context of a test client

[Yo-Yo Ma]

Hi Anss, thanks for the reply.

The queries are identical.


That's the exact reason I posted. Those two examples should essentially be 
the same, save for some sort of operator overloading.

My note at the bottom about providing an empty list instead of the related 
cache when calling ``prefetch_related_objects`` implies that something 
weird is going on with the related cache, and the fact that it only happens 
when using the test client (at least, thus far) makes me think that it 
could possibly even be related to some sort of ``threading.local``, or 
something to that effect.

The models are simple (named according to the example in the original post):

class Foo(models.Model):
title = models.CharField(max_length=255)


class Baz(models.Model):
name = models.CharField(max_length=255)


class Bar(models.Model):
foo = models.ForeignKey('Foo')
baz = models.ForeignKey('Baz')
quantity = models.IntegerField()


My wild guesses: 
>   - some sort of state leak in testing 
>   - non-deterministic bug in prefetch_related (likely caused by random 
> ordering of the rows in the resultset) 
>
> I hope you can provide us more data about this situation, 
>  - Anssi 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/SirWYaLJLs4J.
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.

Re: Github tags

[Yo-Yo Ma]

+1

On Monday, October 29, 2012 5:18:48 AM UTC-4, Jan Bednařík wrote:
>
> There is also related ticket https://code.djangoproject.com/ticket/19141 
>
> Jan 
>
>
> On Mon, Oct 29, 2012 at 3:36 AM, Matt Austin 
> > 
> wrote: 
> > Hi, 
> > 
> > Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5 
> > alpha tagged on the github repository? The tagging seems to have 
> > fallen behind with these releases. 
> > 
> > Thanks, 
> > 
> > -- 
> > Matt 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Django developers" group. 
> > To post to this group, send email to 
> > django-d...@googlegroups.com. 
>
> > To unsubscribe from this group, send email to 
> django-develop...@googlegroups.com . 
> > For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en. 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/qWKMQb_tsmAJ.
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.

Re: Github tags

[Jacob Kaplan-Moss]

Just so y'all know, this is on the todo list. We want to start doing
signed tags (something cool that we can do now that we use git), so
we've been putting it off until we figure out exactly how to do that
(and, more importantly, who should do the signing.)

Jacob

On Mon, Oct 29, 2012 at 10:30 AM, Yo-Yo Ma  wrote:
> +1
>
>
> On Monday, October 29, 2012 5:18:48 AM UTC-4, Jan Bednařík wrote:
>>
>> There is also related ticket https://code.djangoproject.com/ticket/19141
>>
>> Jan
>>
>>
>> On Mon, Oct 29, 2012 at 3:36 AM, Matt Austin 
>> wrote:
>> > Hi,
>> >
>> > Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5
>> > alpha tagged on the github repository? The tagging seems to have
>> > fallen behind with these releases.
>> >
>> > Thanks,
>> >
>> > --
>> > Matt
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Django developers" group.
>> > To post to this group, send email to django-d...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > django-develop...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/django-developers?hl=en.
>> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/qWKMQb_tsmAJ.
>
> 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.

-- 
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.

Re: Single table inheritance - working implementation

[Craig de Stigter]

Hi Krzysztof and everyone else

Thanks! Your fork looks very promising. I'll review the fork today and
possibly pull changes in if the changes aren't too disruptive. Some more
tests would probably be good.

I've added a New BSD
License
to
the repo to clear up any confusion.

Would other devs be interested in adding something like django-typed-models
to Django core? What kinds of changes would make that more likely?

Cheers
Craig de Stigter

On Tue, Oct 30, 2012 at 2:34 AM, Krzysztof Jurewicz <
krzysztof.jurew...@gmail.com> wrote:

> Hi all,
>
> In February, Craig de Stigter released 
> django-typed-models,
> a package implementing inheritance hierarchy for Proxy models with
> automatic type recasting. I've written a fork of it with additional
> possibility of adding fields to subclasses, therefore achieving a single
> table inheritance implementation similar to Ruby on Rails' STI. This is
> possible mostly thanks to metaclass magic and monkey patching.
>
> The fork's homepage is at https://github.com/KrzysiekJ/django-typed-models. 
> Note that it should be considered early alpha and there is much room for
> optimisation, code cleanup and maybe additional features. Feel free to fork
> and/or add issues.
>
> I don't know yet what to do with licensing since Craig didn't specify any
> license in the original package. Craig, please comment or send me an email.
>
> Regards,
> Krzysztof Jurewicz
>

-- 
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.

Ticket 9722 (pynotify support)

[Aron Griffis]

I've noticed that the auto-reload support isn't kind to my laptop battery,
so I was happy to find that somebody's already done the work to get inotify
support into the autoreloader.  The patches are in
https://code.djangoproject.com/ticket/9722

This ticket seems to have been around for a while without an owner. Is
there something I can do to help get it in?

Thanks,
Aron

-- 
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.

Re: Ticket 9722 (pynotify support)

[Jacob Kaplan-Moss]

Hi Aron --

Thanks for the interest; looks like a pretty nice addition.

Looking at the patch, I see a couple things you could do to help it
get in quicker:

* Update the patch so that it applies against he latest development
trunk. Looks like the patch is 2+ years old, so the chances are it
will no longer apply. You could then upload a new patch to the tracker
or open a pull request over on GitHub and note the pull-request number
in Trac.

* There's no documentation or tests, both of which are usually needed
to get a patch accepted. There probably doesn't need to be much in the
way of documentation -- just a note that if pynotify is installed that
it'll be used. Testing's another story: this is likely to be something
that's really tricky to test. If you come to the conclusion that this
simply can't be tested than that might be OK, but you should
explicitly explain your reasoning behind testing on the ticket page.

Thanks!

Jacob

On Mon, Oct 29, 2012 at 4:16 PM, Aron Griffis  wrote:
> I've noticed that the auto-reload support isn't kind to my laptop battery,
> so I was happy to find that somebody's already done the work to get inotify
> support into the autoreloader.  The patches are in
> https://code.djangoproject.com/ticket/9722
>
> This ticket seems to have been around for a while without an owner. Is there
> something I can do to help get it in?
>
> Thanks,
> Aron
>
> --
> 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.

-- 
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.

Re: Ticket 9722 (pynotify support)

[Aron Griffis]

Hi Jacob,

Sounds great. I'll update the patch and see if I can come up with some
tests. Thanks!

Aron

On Mon, Oct 29, 2012 at 5:32 PM, Jacob Kaplan-Moss wrote:

> Hi Aron --
>
> Thanks for the interest; looks like a pretty nice addition.
>
> Looking at the patch, I see a couple things you could do to help it
> get in quicker:
>
> * Update the patch so that it applies against he latest development
> trunk. Looks like the patch is 2+ years old, so the chances are it
> will no longer apply. You could then upload a new patch to the tracker
> or open a pull request over on GitHub and note the pull-request number
> in Trac.
>
> * There's no documentation or tests, both of which are usually needed
> to get a patch accepted. There probably doesn't need to be much in the
> way of documentation -- just a note that if pynotify is installed that
> it'll be used. Testing's another story: this is likely to be something
> that's really tricky to test. If you come to the conclusion that this
> simply can't be tested than that might be OK, but you should
> explicitly explain your reasoning behind testing on the ticket page.
>
> Thanks!
>
> Jacob
>
> On Mon, Oct 29, 2012 at 4:16 PM, Aron Griffis 
> wrote:
> > I've noticed that the auto-reload support isn't kind to my laptop
> battery,
> > so I was happy to find that somebody's already done the work to get
> inotify
> > support into the autoreloader.  The patches are in
> > https://code.djangoproject.com/ticket/9722
> >
> > This ticket seems to have been around for a while without an owner. Is
> there
> > something I can do to help get it in?
> >
> > Thanks,
> > Aron
> >
> > --
> > 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.
>
> --
> 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.
>
>

-- 
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.