Re: Django ORM query syntax enhancement

Hi all, Here is a raw pull request, allowing lookup instances passing to filter method There are two new test cases working: 1. Passing lookup with F object: Article.objects.filter(GreaterThan(F('id'), Value(5))) 2. And passing lookup with transforms: Article.objects.filter(Contains(Upper(Low

Re: Django ORM query syntax enhancement

I think you forgot the PR link Alexey. I'd like to have a look at the changes you've made. I'm not sure about the extensions to F() just yet, I'm hoping they aren't actually needed for your patch to work, but will need to review to be sure. Cheers On Monday, 19 October 2015 21:49:37 UTC+11, Al

Re: Django ORM query syntax enhancement

this is the PR josh https://github.com/django/django/pull/5443 On Monday, October 19, 2015 at 5:09:14 PM UTC+6, Josh Smeaton wrote: > > I think you forgot the PR link Alexey. I'd like to have a look at the > changes you've made. I'm not sure about the extensions to F() just yet, I'm > hoping th

Re: Django ORM query syntax enhancement

Here is a link https://github.com/django/django/pull/5443, sorry :) Making F object as expression wasn't required, but I still had to create FieldExpression wrapper, which wrapped F object. Eventually, I thought it would confuse people, especially taking in account F objects referenced in doc a

Re: Django ORM query syntax enhancement

I did similar work in https://github.com/django/django/pull/4801. I aimed for 1.9, but had to defer the work due to problems with .exclude() filtering. The problem is that if you query with .exclude(LessThan(F('friends__age'), 30)), you'll get different results than with .exclude(friends__age__lt=

Re: Django ORM query syntax enhancement

Hey Anssi, Just pushed test_lookup_exclude and test_lookup_exclude2, which passed successfully. Can you please review if they cover exactly described case? Thanks, Alexey On Monday, October 19, 2015 at 2:28:42 PM UTC+3, Anssi Kääriäinen wrote: > > I did similar work in https://github.com/djang

Re: Fellow Report - October 17, 2015

Thanks for the thorough report Tim. We are glad you had a good experience here at Microsoft. I will send out a similar report by the end of the week on the SQL Server/Azure SQL Discussion on the mailing list: https://groups.google.com/forum/#!topic/django-developers/FbBcUCzrSZo. You bring out s

should manage.py test run system checks?

A ticket [1] and pull request [2] note that `manage.py test` ran the system checks in Django 1.7 (as a side effect of call_command('migrate')), but this is no longer the case in Django 1.8 since call_command() doesn't trigger the system checks anymore. me: I'm of the opinion that running the sy

[ANNOUNCE] Django 1.9 beta 1 released

We've made the second release on the way to Django's next major release, Django 1.9! With a month and a half until the scheduled final release, we'll need timely testing from the community to ensure an on-time and stable release. Check out the blog post: https://www.djangoproject.com/weblog/201

Re: Fellow Report - October 17, 2015

Tim gave a good overview of the week. I'll focus my response on the MSSQL roadmap. On Sat, Oct 17, 2015 at 8:36 PM, Tim Graham wrote: > * Discussed the long-term roadmap for MSSQL support in Django. I'll let > Michael speak to the details of this. > I had the opportunity to speak with several e

makemigrations --exit; exit status feels backwards from conventions

Before posting this, I've read through the full thread "sys.exit(1) from makemigrations if no changes found" at . I fully agree with the spirit of the change. I already find the feature useful in CI. However, after using t

Re: should manage.py test run system checks?

How about making them opt-out instead of opt-in (for instance with a --skip-checks flag)? That way anybody who is aware of the fact that checks are being run every time tests are run and is seeking an increase in performance can choose to opt-out, whereas anybody not aware (or at least not full

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

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

Re: should manage.py test run system checks?

Sorry for the double post, but I think allowing two levels of control, by possibly even adding a setting: TEST_SKIP_CHECKS (in addition to the --skip-checks management command flag) which defaults to False would be ideal. That way any developer worried about test performance can just add this f