Re: Fellow Report - October 17, 2015

[Aymeric Augustin]

2015-10-20 5:04 GMT+02:00 Michael Manfre :

> My long term plan is to switch out ADO for replaceable ODBC and FreeTDS.
> This may follow the current pattern Aymeric started when he created
> django-pymssql, or have them both in django-mssql.


For the record, django-sqlserver did that as well. In django-pymssql, I
chose to wrap django-mssql instead of forking it to avoid the having to
maintain a fork until a better solution is available.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mUvHJaT-pgZBYDesSVVir8j-vcXCn-D9RMe1nJivBJ54g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: should manage.py test run system checks?

[Aymeric Augustin]

2015-10-20 2:48 GMT+02:00 Tim Graham :

> me: I'm of the opinion that running the system checks as part of the manage.py
> test command should be opt-in (for example, by writing a test that
> asserts the call_command('check') output is empty. For example, when
> debugging a single test, it doesn't seem necessary to have the overhead of
> running check.
>
I share this opinion. Single-test run time is a very important use case,
not only for TDD practitioners, but also for everyone who tries to fix a
stubborn failing test.



-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mWRHomvmhnRBM-AcRupdwgXZ4xkN33P3DrBVxLFY3ZJsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: should manage.py test run system checks?

[Shai Berger]

Just brainstorming : by all of the above, it would seem that the best default 
is to run checks unless specific tests are selected. Of course, this could be 
perceived as inconsistent, and that would be a problem. 

On 20 באוקטובר 2015 10:04:17 GMT+03:00, Aymeric Augustin 
 wrote:
>2015-10-20 2:48 GMT+02:00 Tim Graham :
>
>> me: I'm of the opinion that running the system checks as part of the
>manage.py
>> test command should be opt-in (for example, by writing a test that
>> asserts the call_command('check') output is empty. For example, when
>> debugging a single test, it doesn't seem necessary to have the
>overhead of
>> running check.
>>
>I share this opinion. Single-test run time is a very important use
>case,
>not only for TDD practitioners, but also for everyone who tries to fix
>a
>stubborn failing test.
>
>
>
>-- 
>Aymeric.
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "Django developers  (Contributions to Django itself)" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to django-developers+unsubscr...@googlegroups.com.
>To post to this group, send email to
>django-developers@googlegroups.com.
>Visit this group at http://groups.google.com/group/django-developers.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/CANE-7mWRHomvmhnRBM-AcRupdwgXZ4xkN33P3DrBVxLFY3ZJsA%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0D3DABDD-4B1F-4B9C-8145-7C32BCCC3167%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket #25328 - LiveServerTestCase with HTTPS - opinions?

[Jakub Gocławski]

The argument that adding LiveServerTestCase with HTTPS as a separate tool 
is easy - it is valid in this case, after my refactor has been merged.

The real use-case when I (and someone else may) need 
HTTPSLiveServerTestCase is the one I wrote before:

   - in a HTTPS-only application you can use custom secure cookies (not 
   only CSRF or session, but application specific). But if you don't have a 
   HTTPSLiveServerTestCase you cannot test it with Selenium as those cookies 
   won't be passed to the server, which runs as HTTP
   
I'm not aware of any other issues, but maybe there is something more.

But my main point and what I wanted to suggest is that Django should 
encourage writing HTTPS-only applications. In my opinion HTTPS as default 
(instead of HTTP as default) should be seriously considered and thus, 
testing a HTTPS application shouldn't require to install external packages. 
HTTPS is the future considering the SPDY/HTTP2 protocol development. 
Getting and deploying a certificate will also be much easier when Let's 
Encrypt launches in about a month from now.
This argument holds for runserver as well, but it's indeed another thread, 
so I will stick to running tests here :)

So "the problem" solved by HTTPSLiveServerTestCase is rather minor and can 
be achieved by using an external app. 
But "the idea" to encourage HTTPS is another thing and adding a test case 
is a small step into this direction. And of course adding a HTTPS runserver 
would be a bigger step :)

Considering the above and the discussion about HTTPS runserver - I will 
just release the testcase as a separate app.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3649e944-a9aa-4b89-b9c2-d112f7ae7923%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report - October 17, 2015

[Michael Manfre]

On Tue, Oct 20, 2015 at 3:02 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> 2015-10-20 5:04 GMT+02:00 Michael Manfre :
>
>> My long term plan is to switch out ADO for replaceable ODBC and FreeTDS.
>> This may follow the current pattern Aymeric started when he created
>> django-pymssql, or have them both in django-mssql.
>
>
> For the record, django-sqlserver did that as well. In django-pymssql, I
> chose to wrap django-mssql instead of forking it to avoid the having to
> maintain a fork until a better solution is available.
>

Thanks for the reminder. I forgot about django-sqlserver. I'll also
evaluate that backend.

Regards,
Michael

-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBu6rHaLXec2ZN-LHhCxb0w3HLqZHB1hWNNxYGsHGyQBZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report - October 17, 2015

[Marc Tamlyn]

This is awesome news for Django's status in enterprise, great work everyone.

I hope something comes from the Microsoft Fellow concept, that would be
brilliant.

On 20 October 2015 at 15:18, Michael Manfre  wrote:

>
> On Tue, Oct 20, 2015 at 3:02 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> 2015-10-20 5:04 GMT+02:00 Michael Manfre :
>>
>>> My long term plan is to switch out ADO for replaceable ODBC and FreeTDS.
>>> This may follow the current pattern Aymeric started when he created
>>> django-pymssql, or have them both in django-mssql.
>>
>>
>> For the record, django-sqlserver did that as well. In django-pymssql, I
>> chose to wrap django-mssql instead of forking it to avoid the having to
>> maintain a fork until a better solution is available.
>>
>
> Thanks for the reminder. I forgot about django-sqlserver. I'll also
> evaluate that backend.
>
> Regards,
> Michael
>
> --
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAGdCwBu6rHaLXec2ZN-LHhCxb0w3HLqZHB1hWNNxYGsHGyQBZQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GH%2BQ50De2LoUzCptch6rnhuQf2uEFQfE7xV2%2BcpZdMUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: makemigrations --exit; exit status feels backwards from conventions

[Marc Tamlyn]

I see what you mean and the inherent problems with the design. However
fundamentally the command you are running is "make some migrations", and
the "I don't have any to make" step is clearly an error case, not a success
case. In particular it would be very wrong for the real "I want to make
some migrations" command to return a non-zero code when it does
successfully create some.

The only real solution I can see is a separate command, or something like
makemigrations --check.

On 20 October 2015 at 05:20, Jon Dufresne  wrote:

> Before posting this, I've read through the full thread "sys.exit(1)
> from makemigrations if no changes found" at
> <
> https://groups.google.com/d/topic/django-developers/I3M6B-wYYd8/discussion
> >.
>
> I fully agree with the spirit of the change. I already find the
> feature useful in CI. However, after using this feature on a CI
> server, I find the exit status backwards compared to typical commands.
> The makemigrations command returns status 0 to indicate CI failure
> (migrations missing) and 1 to indicate CI pass (continue to the next
> CI stage).
>
> Typically status 0 indicates pass and non-zero indicates failure. By
> following the typical exit status conventions, commands can explicitly
> return a non-zero status when detecting a failure or the Python
> runtime may return a non-zero status if something goes terribly wrong;
> such as an unhandled exception.
>
> Someone that is accustomed to typical exit status conventions might
> naively use the makemigrations command:
>
> ./manage.py makemigrations --dry-run --exit
>
> The expectation: the next stage should continue if there are no new
> migrations (the developer did everything they were supposed to do and
> included migrations). However, the above command will return status 1,
> not 0, if there are no new migrations.
>
> OK, we can test for that. Maybe change the command to:
>
> ! ./manage.py makemigrations --dry-run --exit
>
> That is, interpret the exit status opposite of what one would
> typically expect. Immediately, this looks backwards compared to
> typical shell scripting. But what happened to the "terribly wrong"
> scenario? For example, what if a developer mistakenly added an
> incorrect setting that caused an ImproperlyConfigured error? If this
> were to happen, I would want the above command to fail and stop the CI
> pipeline.
>
> So maybe the next step would be to check explicitly for exit code 1.
>
> ./manage.py makemigrations --dry-run --exit; test $? -eq 1
>
> Now it looks like we're hacking around something.
>
> Additionally, Python exits with status 1 for unhandled exceptions. So
> the above command would still pass the CI stage for an unhandled
> exception. Further Django's BaseCommand.run_from_argv() also exits
> with status code 1 on CommandError, so again, it would pass the CI
> stage for anything that triggers this sort of error.
>
> It seems exit status 1 is overloaded to mean "all migrations are
> accounted for, continue to the next stage of CI", and "something went
> terribly wrong".
>
> This is why I feel the exit status is backwards from what is typically
> expected.
>
> I would like to suggest we find a better way to interface with CI
> servers. That is return 0 when there are no migrations (continue to
> the next stage) and non-zero for both "migrations missing" and
> "something went terribly wrong".
>
> I suggest maybe adding a system check for missing migrations. The
> check could report an error, when they are missing.  The check
> framework seems like a natural command to be used by CI servers
> anyway, so this seems like a good place. The missing migration
> detection already exists, so the same code could be leveraged for this
> check.
>
> I'm also open to other suggestions on creating a more convention exit
> status.
>
> If there is agreement and the proposal sounds good, I can follow
> through with a ticket and code changes.
>
> Cheers,
> Jon
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADhq2b5YDr-HB5sUdwKK-K2awQZk7qUhJJdaU%2B4SH_6nx9x%3D5w%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group

Re: makemigrations --exit; exit status feels backwards from conventions

[Shai Berger]

On Tuesday 20 October 2015 19:51:36 Marc Tamlyn wrote:
> I see what you mean and the inherent problems with the design. However
> fundamentally the command you are running is "make some migrations", and
> the "I don't have any to make" step is clearly an error case, not a success
> case. In particular it would be very wrong for the real "I want to make
> some migrations" command to return a non-zero code when it does
> successfully create some.
> 
> The only real solution I can see is a separate command, or something like
> makemigrations --check.

Agreed. In particular,

> On 20 October 2015 at 05:20, Jon Dufresne  wrote:
> > 
> > It seems exit status 1 is overloaded to mean "all migrations are
> > accounted for, continue to the next stage of CI", and "something went
> > terribly wrong".
> > 

No; it seems the "makemigrations" command is overloaded to mean both "make 
migrations for me" and "verify that no migrations need to be made".

HTH,
Shai.

Re: makemigrations --exit; exit status feels backwards from conventions

[Shai Berger]

On Tuesday 20 October 2015 20:09:36 I wrote:
> On Tuesday 20 October 2015 19:51:36 Marc Tamlyn wrote:
> > I see what you mean and the inherent problems with the design. However
> > fundamentally the command you are running is "make some migrations", and
> > the "I don't have any to make" step is clearly an error case, not a
> > success case. In particular it would be very wrong for the real "I want
> > to make some migrations" command to return a non-zero code when it does
> > successfully create some.
> > 
> > The only real solution I can see is a separate command, or something like
> > makemigrations --check.
> 
> Agreed. In particular,
> 
> > On 20 October 2015 at 05:20, Jon Dufresne  wrote:
> > > It seems exit status 1 is overloaded to mean "all migrations are
> > > accounted for, continue to the next stage of CI", and "something went
> > > terribly wrong".
> 
> No; it seems the "makemigrations" command is overloaded to mean both "make
> migrations for me" and "verify that no migrations need to be made".
> 

On second thought, I take that back.

As is evident from the discussion Jon cited[1], the --exit flag was intended to 
be used as Marc's --check. Jon is basically correct in his analysis, and I 
think the root issue is that "--exit" is just a bad name for "--check".

[1] https://groups.google.com/d/topic/django-developers/I3M6B-wYYd8/discussion

Re: makemigrations --exit; exit status feels backwards from conventions

[Jon Dufresne]

On Tue, Oct 20, 2015 at 1:18 PM, Shai Berger  wrote:
> On second thought, I take that back.
>
> As is evident from the discussion Jon cited[1], the --exit flag was intended 
> to
> be used as Marc's --check. Jon is basically correct in his analysis, and I
> think the root issue is that "--exit" is just a bad name for "--check".
>
> [1] https://groups.google.com/d/topic/django-developers/I3M6B-wYYd8/discussion

How would you feel about putting "--exit" on a deprecation path and
replacing it with a "--check" flag? The "--check" flag would return 0
if no migrations are missing and non-zero if they are missing.

Cheers,
Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b79dkVyXPhzVYieSjo%2BTQWs%3DhixqYRpAv539B1YzM3q7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: makemigrations --exit; exit status feels backwards from conventions

[Jon Dufresne]

On Tue, Oct 20, 2015 at 1:48 PM, Jon Dufresne  wrote:
> On Tue, Oct 20, 2015 at 1:18 PM, Shai Berger  wrote:
>> On second thought, I take that back.
>>
>> As is evident from the discussion Jon cited[1], the --exit flag was intended 
>> to
>> be used as Marc's --check. Jon is basically correct in his analysis, and I
>> think the root issue is that "--exit" is just a bad name for "--check".
>>
>> [1] 
>> https://groups.google.com/d/topic/django-developers/I3M6B-wYYd8/discussion
>
> How would you feel about putting "--exit" on a deprecation path and
> replacing it with a "--check" flag? The "--check" flag would return 0
> if no migrations are missing and non-zero if they are missing.

To get a sense of what this would mean, I've created a POC with this
idea at: https://github.com/django/django/pull/5453

If the idea and design is well received, I'll create a ticket and
continue with it.

Thanks,
Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b47ioAcHa9wB0baV1KNGaO3uOdGhw68Pt5S4s1Y-GZhZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: makemigrations --exit; exit status feels backwards from conventions

[Gavin Wahl]

In your case, successfully creating a migration indicates a failure. Why do 
you object to using a ! to communicate this?

! ./manage.py makemigrations

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/61887548-63b9-4a45-b1f3-689650e84154%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Contributing to a module that does not seem to be covered by tests extensively (djanog.db.models.expressions)

[Josh Smeaton]

Hi David,

Unfortunately we've missed the cutoff for 1.9, this will have to wait to be 
released with 1.10. I didn't want to delay the beta date with what could 
potentially be a drawn out patch (validating names, locations of classes, 
accuracy of docs). Further, we probably shouldn't have added an argument to 
DateTimeExtract (lookup_name?) during an alpha.

1. I agree, they are probably the correct places to put those 
functions/classes. We can then import lookups.datetime.* into lookups so 
that they are correctly registered.
2. We can definitely create an Extract(field, lookup='month') type for 
1.10. My objection was changing the signature of that class during an 
alpha. Now that we're targeting 1.10, we can go ahead with this.

I don't think we need to create a class factory though, since we're only 
going to be using this type in a small finite set of classes.

class Month(Extract):
lookup = 'month'
Month(field)

and 

Extract(field, lookup='month')

Should be equivalent and both be options.

Cheers

On Tuesday, 20 October 2015 16:27:10 UTC+11, David Filipovic wrote:
>
> Hey, Josh,
>
> The 1st Beta was released today. Should we still try to make it into 1.9, 
> or is it too late? 
>
> I can get started on the move tomorrow (Tuesday) night. I suggest:
>
> 1. moving all date/time related transforms into lookups/datetime.py, and 
> leaving all the other ones in lookups/__init__.py.
> (this is important because these transforms still have to be registered as 
> lhs lookups in __init__.py, in order not to break any existing 
> functionality)
>
> 2. Renaming DateTransform to DateTimeExtract (to match lower-level API) 
> [possibly split into DateExtract and TimeExtract] and make everything work 
> through that interface. Regarding this, you mentioned we don't have an 
> opportunity to do Extract(lookup='month') type API. Is there a reason for 
> this? It could be easily done with the __new__ magic method and if we need 
> all the other transform classes available, for some reason, we could just 
> initialize them with a DateTimeExtractFactory, for instance. So something 
> like: MonthTransform = DateTimeExtractFactory('month').
>
> That way we can just make the DateTimeTransform public, it would be easy 
> to document and testing would be a breeze. What do you think?
>
> I'll create a new ticket and get started on this tomorrow after work. I 
> expect to have a PR compiled by Wednesday night, but take a little longer.
>
>
> On Sunday, October 18, 2015 at 9:56:51 PM UTC-4, Josh Smeaton wrote:
>>
>> > However, the way I see it here, the right hand side lookup interface is 
>> all broken up and scattered across multiple modules and classes, many of 
>> which are undocumented.
>>
>> Yes, that's what we should try to fix in 1.9 before it reaches Beta. I'm 
>> mostly interested in the DateTransform classes for the moment, since they 
>> were only recently added and we have an opportunity to improve them.
>>
>> Firstly, I think they should be renamed. I'm not sure if we should go for 
>> Month() or ExtractMonth() or something else entirely. We don't have the 
>> opportunity to do an Extract(lookup='month') type of API just yet which may 
>> be a better overall API. Does anyone have thoughts on naming?
>>
>> Once they've been named, we should consider where the best place for them 
>> to reside should be. I'm guessing db/functions.py with the rest of the 
>> dbfunctions, but they could easily go into a submodule type arrangement, 
>> either lookups/datetime.py or functions/datetime.py.
>>
>> Then the ones we're making public need to be documented. This should be 
>> fairly straightforward once we've achieved the above.
>>
>> We need to get this done quickly in order to make 1.9. The beta will be 
>> released next week, so the timeline is the next few days. Opinions 
>> definitely welcome.
>>
>> > MyModel.objects.filter(date1__month=F('date2__month'))
>>
>> This is an option in the future. Charettes has linked to a discussion on 
>> alternative syntax. So, for the moment, let's just get the object based 
>> right hand side documented, and we can work on alternatives later.
>>
>> > Additionally, is there a reason why Combinable/F couldn't figure out 
>> its own output_field type (at least in some cases? e.g (DateField - 
>> DateField) --> DurationField)
>>
>> If you can find an appropriate place for this logic to live then I'm all 
>> for it. ExpressionWrapper is cumbersome, but it's also necessary for user 
>> based combinations where the base F/Combinable/Expression has no knowledge 
>> of output_type combinations.
>>
>> Cheers
>>
>> On Saturday, 17 October 2015 14:08:49 UTC+11, David Filipovic wrote:
>>>
>>> Hi Josh,
>>>
>>> Thanks so much for your input, both here and on the ticket I referenced.
>>>
>>> You were correct, MonthTransform did work. Essentially, this piece of 
>>> code worked in django 1.9:
>>>
>>> MyModel.objects.filter(date1__month=MonthTransform('date2'))
>>>
>>>
>>> However, the way I s