Django 3.0 Release Notes - ASGI

2019-10-14 Thread Josh Smeaton
A co-worker just linked me to https://docs.djangoproject.com/en/dev/releases/3.0/#asgi-support and asked me (basically) if we can start doing all kinds of async work in one of our projects. Unfortunately, I didn't really know how to answer. Preface: I haven't followed the ASGI plan very

Re: Explore integrating django-docker-box in some way?

2019-10-08 Thread Josh Smeaton
available for running >>>> right away. We can make this smaller, for sure, but we can also suggest >>>> people download this beforehand (i.e at their hotel). >>>> >>>> I don’t know how feasible this is but it’s also very easy to run a >>>> ca

Re: Explore integrating django-docker-box in some way?

2019-10-04 Thread Josh Smeaton
ts and configuring docker to use a local mirror >> on the network is a one-line change for atendees. >> >> >> >> >> On 4 December 2018 at 23:52:42, Josh Smeaton (josh@gmail.com) wrote: >> >> Size of the image could definitely be a concern, esp

Re: Django LTS support time

2019-08-14 Thread Josh Smeaton
I don't think the DSF has the capacity or the will to run a business offering paid support contracts. But nothing is stopping an enterprising individual or company from doing so. All security patches are made public (eventually) and backporting fixes would be fairly low effort.

Re: Creating a new "Triage & Review Team"

2019-08-14 Thread Josh Smeaton
I think that's sensible, including making the team public. > This struck me as a little absurd: if we weren't going to dissolve it, Nick should definitely be part of the old "Django Core". It's not done yet, and while we're in this limbo stage, we're potentially missing out on some good

Re: Make Development More Accessible

2019-08-07 Thread Josh Smeaton
Mariatta has put together a some PEPs for migrating CPython issues over to GitHub. https://www.python.org/dev/peps/pep-0581/ proposing the migration. https://www.python.org/dev/peps/pep-0588/ migration plan. Django and Cpython are not the same, so there'll be substantial differences. But it's

Re: Redis cache support in core

2019-06-27 Thread Josh Smeaton
go_redis.cache.RedisCache` -- > > it's basically the way it works with DB backends, I don't see why it > > wouldn't be a good idea for cache as well. > > > > Ivan. > > > > On Thu, Jun 20, 2019, 04:02 Josh Smeaton > wrote: > > > Celery explicitly

Re: Redis cache support in core

2019-06-19 Thread Josh Smeaton
ndency? > Celery, for example, does that: you can just install celery[redis] without > having to figure out what other packages you need to enable redis support. > > Ivan. > > On Wed, Jun 19, 2019 at 6:44 AM Josh Smeaton > wrote: > >> There are already several 3rd

Re: Redis cache support in core

2019-06-18 Thread Josh Smeaton
There are already several 3rd party packages that implement redis as a django cache backend, for example https://github.com/niwinz/django-redis We already have a base class for cache backends - and several implementing it (such as memcache). I don't think there's much benefit taking on another

Re: Faster Migrations! But at what cost?

2019-05-21 Thread Josh Smeaton
Just to add some stats to the conversation, our largest project has ~90 apps (+3rd party), and 240 migration files. This is after we reset our migration history when migrating from 1.8 -> 1.11 (just over a year ago). We would have had well in excess of 800 migration files at that point. To

Re: Proposal to format Django using black

2019-04-25 Thread Josh Smeaton
To answer the question about decision making... Usually a decision is made if there’s reasonable consensus in the discussion or after a vote. If no clear consensus can be reached with the core team, then a decision can be escalated to the technical board for a vote. In the future, if the core

Re: Proposal to format Django using black

2019-04-24 Thread Josh Smeaton
Whoops, you are correct. It did not at the time I added black to my projects, my information was quite out of date. Sorry for the wrong correction! On Wed, 24 Apr 2019 at 22:51, Florian Apolloner wrote: > > On Wednesday, April 24, 2019 at 1:25:55 PM UTC+2, Josh Smeaton wrote: >> &

Re: Proposal to format Django using black

2019-04-24 Thread Josh Smeaton
Black does not support disabling formatting by block with a comment. It removes all choice except for the upfront choices of length and string normalisation. On Wed, 24 Apr 2019 at 20:22, Rene Fleschenberg wrote: > Hi > > > The arguments against a particular code style will never stop. In this

Re: Proposal to format Django using black

2019-04-24 Thread Josh Smeaton
FWIW, I'd be opposed to YAPF at all, but especially over Black. The community (that is, large projects that aren't Django) are standardising around Black - a single unambiguous format style. Having a slightly different format to everybody else I see as backwards. Contributors would also likely

Re: Proposal to format Django using black

2019-04-16 Thread Josh Smeaton
ng them? Must be even better for productivity. > > Ivan. > > On Wed, Apr 17, 2019 at 12:35 AM Josh Smeaton > wrote: > >> Ivan, what you’re talking about is subjective code formatting, and lends >> itself to extreme bikeshedding and little consensus. Django already has a

Re: Proposal to format Django using black

2019-04-16 Thread Josh Smeaton
Ivan, what you’re talking about is subjective code formatting, and lends itself to extreme bikeshedding and little consensus. Django already has a formatting standard that mergers try to enforce at review and commit time. But it’s time consuming, prone to missing things, and requires lots of back

Re: Proposal to format Django using black

2019-04-15 Thread Josh Smeaton
Yes, let’s not discuss the tools choice in quotes, that’s for another place. To provide some information though, black will not convert single quote strings if the string itself contains a double quote. It won’t escape the character, it’ll use single quotes. On Mon, 15 Apr 2019 at 18:48, Kye

Re: Proposal to format Django using black

2019-04-14 Thread Josh Smeaton
Agree with Florian that the progressive rollout is more trouble than it's worth. Tangling up feature changes with whole file formatting will make it harder to review changes, but will also be more difficult to use tools like git blame. As for disagreeing with some of Blacks choices - you learn

Re: Filterable subqueries ...

2019-03-12 Thread Josh Smeaton
With regard to the stunning silence you're witnessing, it's my guess that you haven't made yourself clear enough in a concise way. The stackoverflow post is large, and doesn't point out what's missing very clearly. What is the SQL you want? What is the SQL you're getting, and what is the

Re: Add an defer=True option for model fields

2019-02-20 Thread Josh Smeaton
There is a ticket for this one already, filed 4 years ago by me :) https://code.djangoproject.com/ticket/24096 There are a few options described, but I think `defer=True` was winning out. I don't think we considered an `undefer`, but a `defer(None)` would fix that. Once that API is built, then

Re: Will Django ever CompositePrimaryKeys?

2019-02-19 Thread Josh Smeaton
To add - there's definitely appetite for this feature, but it's a difficult one, and no one has stepped up to do it. There are DEP drafts that cover pieces: https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst

Re: Validation of m2m

2019-02-16 Thread Josh Smeaton
Considering https://code.djangoproject.com/ticket/12938 is still marked as "open" and https://code.djangoproject.com/ticket/24731 is more or less a duplicate (is there a reason it isn't closed as a dupe specifically?), I don't think any more consensus is really required. The problem seems

Re: Google Summer of Code 2019

2019-02-15 Thread Josh Smeaton
If you really think you want to work on a deployment project, you should get the requirements together very quickly, so someone on this list can sanity check that it's something both feasible and useful. I have done a **lot** of different deployments, and other than deploying to heroku, they

Re: Use CDN for djangoproject.com

2019-02-14 Thread Josh Smeaton
Cloudflare have many SSL options, including fully encrypted and authenticated comms all the way through (terminate and reconnect). Typically done by having a “hidden” origin domain that also hosts a certificate. I’m unsure if it’s possible to have both origin and front hosting the same name so

Re: Use CDN for djangoproject.com

2019-02-13 Thread Josh Smeaton
Why do we not want to use Cloudflare? FWIW I agree that the docs site performance is not great (also from melbourne) - but I'd still suffer the performance hit over going via RTD mirrors for familiarity. On Tuesday, 12 February 2019 18:34:09 UTC+11, Florian Apolloner wrote: > > Especially

Re: include only columns from selected related models in select_related query

2019-02-13 Thread Josh Smeaton
Personally, I depend on this behaviour, but it's only because I'm aware of it. Others would be too though, so we can't just make that change (not that you're suggesting that approach). One approach I think could be good would be:

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-10 Thread Josh Smeaton
For the vast majority of users, right now, Vue or React are the only real options. Let's not try predicting the future, and just focus on what the trends currently are. Users going for newer targets are likely more advanced, and can figure out the necessary changes. Aymerics articles are

Re: Proposal to re-open #27017 (updating only dirty fields in save())

2019-01-30 Thread Josh Smeaton
That's a +1 from me. I've certainly hit the bugs you've mentioned before, and I can't think of a good reason not to do dirty field tracking, especially if it were to be opt in. Bikeshedding a little bit, rather than having a global setting, I'd rather see an option on Options/Meta so that opt

Re: Google Summer of Code 2019

2019-01-25 Thread Josh Smeaton
Other ideas can be found in the DEPS repo too: https://github.com/django/deps/pulls The only one of those 3 that would be GSOC doable (IMO) would be the query expression language one. On Friday, 25 January 2019 01:43:13 UTC+11, Carlton Gibson wrote: > > Perhaps it's partly the GSoC doesn't

Re: revisiting the Python version support policy

2019-01-22 Thread Josh Smeaton
Don't discount being able to use features from newer versions of python within Django itself. https://docs.python.org/3/whatsnew/3.6.html - dicts are more performant - dicts/kwargs/class attributes are ordered (cpython implementation detail for 3.6 - allowing us to consider removing descriptor

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-18 Thread Josh Smeaton
If we were happy with that particular implementation, then I'd prefer adding it as an official subclass thats importable for users rather than just dumping the code to the docs. But I guess the issue is a slippery slope - how many subclasses do we add for various ModelAdmin use cases. It's

Re: What do you think about unify templates feature?

2019-01-18 Thread Josh Smeaton
Are you using https://docs.djangoproject.com/en/2.1/ref/templates/api/#django.template.loaders.cached.Loader in your tests? And you should find a way to test rendering from the command line, which will allow you to get much better timing information. On Friday, 18 January 2019 20:40:29

Re: Widening participation (Thoughts from DjangoCon)

2018-12-11 Thread Josh Smeaton
ier to entry which I think we should be aiming towards. If we are > looking to expand the development group and get more people onboard we may > need to shake things up, as the status quo is problematic in that area. > > On 11 December 2018 at 12:04:32, Josh Smeaton (josh.s...@gmail.com >

Re: Widening participation (Thoughts from DjangoCon)

2018-12-11 Thread Josh Smeaton
I don't think something like Jira would even be a consideration. The only reason Github issues would be a consideration is if the group thought the onboarding experience (being where users already are with a tool they're already familiar with) would have more value than sticking with with the

Re: A faster paginator for django

2018-12-08 Thread Josh Smeaton
I think most people would typically sort/paginate on the primary key field, which still exhibits a linear scan, where the first few pages are fast and the last few pages take significantly longer. Just wanted to call that out in case there were listeners thinking an index solves the problem.

Re: Explore integrating django-docker-box in some way?

2018-12-04 Thread Josh Smeaton
es at most. Hopefully this should improve the > experience at sprints, however the current Dockerfile weighs in at 650+mb > so the problem may switch from ‘it is hard to set up an environment’ to ‘it > is hard to download one’! > > > > > On 5 November 2018 at 23:02:30, Josh Sme

Re: TestCase.setUpTestData in-memory data isolation.

2018-11-28 Thread Josh Smeaton
Our project also suffers extensively with mutating objects assigned from setUp, preventing us from moving most of our tests to setUpTestData. I'll likely begin using your pypi package right away, thanks Simon! Backward compat issues are probably likely - but they'd be in test cases

Re: Add Python 3.7 support for Django 1.11?

2018-11-17 Thread Josh Smeaton
Good merge! Should this also be a policy change, or is it better to maintain a position of "if it's relatively easy and unobtrusive"? On Sunday, 18 November 2018 10:08:43 UTC+11, Tim Graham wrote: > > Okay, I've merged the PR, https://github.com/django/django/pull/10654. > > On Saturday,

Re: Allow querying JSONField with F objects #29769

2018-11-13 Thread Josh Smeaton
Hi Mani, No response can mean either the readers here do not have the same problem and have no comment, or your implementation does not require much discussion. In any case, you could continue with the process by proposing a formal patch, and getting someone to review it once it meets the

Re: Remove pyinotify autoreloader support

2018-11-05 Thread Josh Smeaton
I ran a slightly modified version of your test code since we have many modules at "top level". "k3" is one of the top level modules that houses a bunch of apps. In total there are about 1340 python files (including recently squashed migrations and tests). Here's the results: Project: 1575

Re: Explore integrating django-docker-box in some way?

2018-11-05 Thread Josh Smeaton
I'm sorry I haven't had the time to review or contribute yet, but I think it'll be a very useful project - especially for new contributors that might have a little docker experience. The current vagrant solution is heavy, does not work properly on windows and some linuxes, and isn't that easy

Re: backend specific tests

2018-11-05 Thread Josh Smeaton
I don't think there's a full list of extensions the test suite uses, but https://docs.djangoproject.com/en/2.1/ref/contrib/postgres/operations/ would be close to a full set I'd imagine. On Sunday, 4 November 2018 14:43:23 UTC+11, Dan Davis wrote: > > So, the contributor guidelines page about

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

2018-11-05 Thread Josh Smeaton
I'm in the same boat as Simon - I've wanted this many times in the last few months, but only when working at the shell. I'd be +1 for get and -1 for filter also. On Thursday, 1 November 2018 05:12:53 UTC+11, charettes wrote: > > As I've mentioned on the ticket I've been wishing get(pk) could

Re: Widening participation (Thoughts from DjangoCon)

2018-10-28 Thread Josh Smeaton
I strongly dislike Trac in nearly every way. It's hard to search and the filters are next to useless, and the categorisation features we use are not very useful. I believe the better way to search Trac is to use google and site:code.djangoproject.com which is a red flag itself. On Saturday, 27

Re: QuerySet.iterator together with prefetch_related because of chunk_size

2018-10-26 Thread Josh Smeaton
I tend to agree with Tobi. Prefetching silently not working on iterator can be quite confusing, unless you have a good understanding of both APIs. It might be possible to do what you're asking, but it'd mean that django is now actually caching the result when it explicitly says it isn't - even

Re: Jenkins resources

2018-07-12 Thread Josh Smeaton
Hi Matt, The django-box project[0] uses very close to the same ansible configuration that is used to configure all of the Jenkins slaves Django uses with the notable omission of an Oracle builder. Since the repos are separate, there has been some divergence on the Jenkins side of things, but

Re: A Django Async Roadmap

2018-06-09 Thread Josh Smeaton
I think most of what you've laid out sounds great and that pursuing async Django is in the projects best interests. The sync to async and async to sync wrappers that have come out of channels give me much more confidence that this project is doable in a reasonable amount of time with backwards

Re: Proposal: security enhancements

2018-05-02 Thread Josh Smeaton
Most of this sounds really good. As Jacob mentioned, CSP can be quite scary, and sounds like something a novice could try to implement for "good security" and end up causing way more issues. I'd really like to see easy integration for report only mode, with controls that are harder to turn for

Re: #django-dev IRC channel

2018-04-26 Thread Josh Smeaton
Yes - that's probably a good idea! On Thursday, 26 April 2018 05:11:33 UTC+10, Kenneth wrote: > > Hello, > > I was just curious about the #django-dev IRC Channel. > Currently, the only mention for this channel is on the Code of Conduct FAQ > page. >

Re: django-firebird test expressions

2018-04-17 Thread Josh Smeaton
Have you looked into using Cast for this particular query to see if it passes? https://docs.djangoproject.com/en/2.0/ref/models/database-functions/#cast Cast(RawSQL('%s', ['value']), CharField(max_length=10) ? If that worked, then perhaps you could find a clever way to wrap problem

Re: django-firebird test expressions

2018-04-15 Thread Josh Smeaton
It looks correct to me. RawSQL is defining a parameter to be included in the query. The RawSQL expression itself is used in the select and on the left hand side of the WHERE clause, so the parameter needs to be included there. The right hand side of the WHERE clause is a regular string (which

Re: Shouldn't manage.py call python3 instead of python?

2018-04-10 Thread Josh Smeaton
As a datapoint, I've seen roughly 1 person per week in #django IRC confused about specific startup exceptions due to them using python 2 rather than python 3 on Django >= 2.0. Unsure how many of these are due to the shebang. That said, it looks like there are no good solutions other than maybe

Re: Shouldn't manage.py call python3 instead of python?

2018-04-06 Thread Josh Smeaton
I think you're right and PEP394 is the relevant text: https://www.python.org/dev/peps/pep-0394/ TL;DR For now, *python* should refer to python2 and *python3* should be used to refer to python 3. On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote: > > The header of manage.py has:

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

2018-03-29 Thread Josh Smeaton
It sounds like you understand what the current behaviour is, and you think that it would be better modelled with Q objects, is that the case? I can see where you're coming from, as even the docs explain the difference loosely in terms of AND and OR. Q(entry__headline__contains='Lennon') &

Re: Gsoc 2018

2018-03-28 Thread Josh Smeaton
I'm sorry, but the deadline has already passed for applications. It closed on the 27th of March (2 days ago) according to the GSOC timeline https://developers.google.com/open-source/gsoc/timeline. I do note that Django's own timeline mentions April 3rd being the deadline, but I'm not entirely

Adding custom join support to Django

2018-03-28 Thread Josh Smeaton
Someone has again brought up the lack of custom join support in django - specifically LEFT OUTER joins: https://code.djangoproject.com/ticket/29262 I figure it's probably something that we'd like the ORM to support but I don't think we've ever really landed on a design that's palatable. I'd

Re: Gsoc 2018

2018-03-25 Thread Josh Smeaton
Hi there, I don't think the rules for Google Summer of Code allow for "projects" to be documentation only. The extra promo materials would also count as documentation I believe. The relevant rule would be 1.26: https://summerofcode.withgoogle.com/rules/ "Project” means an open source coding

Re: Channels - Groups and discovery

2018-03-25 Thread Josh Smeaton
ng them > low maintenance, and also in letting people solve > dependency/versioning/schema upgrade issues in the way that fits them best. > > Andrew > > On Sun, Mar 25, 2018 at 4:08 PM, Josh Smeaton <josh.s...@gmail.com > > wrote: > >> I see - some kind

Re: Channels - Groups and discovery

2018-03-25 Thread Josh Smeaton
urrent design pattern something > will complain if it's not working right (even though that thing is on the > receiving side not the sending side). > > Andrew > > On Sat, Mar 24, 2018 at 4:31 AM, Josh Smeaton <josh.s...@gmail.com > > wrote: > >> I've finally had the c

Channels - Groups and discovery

2018-03-24 Thread Josh Smeaton
I've finally had the chance to use channels for a project (hack day multiplayer game - hope to release and blog about it some time soon), and I wanted to document some of the rough edges I hit and ask some questions about them. Specifically though, I find the mapping of payload.type to a

Re: GSoC 2018

2018-03-16 Thread Josh Smeaton
the django project wants, and is not something we'd sponsor as part of GSoC. On Saturday, 17 March 2018 07:48:46 UTC+11, Manasvi Saxena wrote: > > Hello Sir, > > On Saturday, March 17, 2018 at 1:57:00 AM UTC+5:30, Josh Smeaton wrote: >> >> I'm confused by your propos

Re: [RFC]GSoC 2018 Test framework improvement

2018-03-16 Thread Josh Smeaton
Hi Billy, This plan sounds more like a plan for a plan. If you're serious about wanting to participate in GSoC, then you need to have **specific** ideas and goals. By this, I mean your proposal should be able to be picked up by anyone and implemented. You're missing any actual feature

Re: GSoC 2018

2018-03-16 Thread Josh Smeaton
I'm confused by your proposal. You state one of the drawbacks with current templating is the readability issues for frontend developers that have templating logic defined within the template. But isn't your proposal to replace html templates with one defined in python? How does this make it

Re: Add Alias or annotations without group-by support?

2018-03-10 Thread Josh Smeaton
2018 14:01:41 UTC+11, Cristiano Coelho wrote: > > It wouldn't work if you also want to order by the annotated value. > > El viernes, 9 de marzo de 2018, 8:27:36 (UTC-3), Josh Smeaton escribió: >> >> Would teaching filter() and friends to use expressions directly solve >

Re: Add Alias or annotations without group-by support?

2018-03-09 Thread Josh Smeaton
Would teaching filter() and friends to use expressions directly solve your issue? You suggested using `alias` upthread, but that's only really required so you can refer to it later? Unless you wanted to refer to the field more than once, having each queryset method respect expressions should

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Josh Smeaton
:04 PM UTC+1, Josh Smeaton wrote: >> >> Or, since this isn't a template tag (facepalm) >> > > Which raises a perfectly valid point: If we were to change this, we will > also need to come up with a new name for the "|safe"-filter. > -- You received this mes

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Josh Smeaton
Or, since this isn't a template tag (facepalm) trusted_html(m.content) trust_html(m.content) On Friday, 23 February 2018 07:46:45 UTC+11, Josh Smeaton wrote: > > Yes I'm not a fan of the *dangerously...* names either. I'm still > somewhat wary of *trust_html* which is a *verb* and co

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Josh Smeaton
vey the gravity of what this actually does. >> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be >> dangerous to trust the literal "Some Content", for example. >> >> Perhaps it could be something a bit more explicit. `no_escape(stri

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-22 Thread Josh Smeaton
2018 21:08:31 UTC+11, Florian Apolloner wrote: > > Yeah, I am also worried about the churn for no gain in my eyes. If users > overuse mark_safe, they will overuse dangerously_trust_html too… > > On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote: >> >

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

2018-02-21 Thread Josh Smeaton
I agree that the names are misleading and we should probably provide better names. I'm wary of deprecating the old names because it'll create a lot of churn (some of which would be the right thing to do). Maybe we could just alias and warn when using the old name, leaving a decision on

Re: Purpose of constant_time_compare?

2018-02-08 Thread Josh Smeaton
I don't doubt that timing attacks can work in practise, but the link you've posted is not this. From the commit message: > There have not been any reports of attempted exploit in the wild. (The vulnerability was discovered through code review.) On Friday, 9 February 2018 09:27:03 UTC+11, Anssi

Re: PR 9583 - Ticket 28643

2018-01-18 Thread Josh Smeaton
I think having Left/Right is the right way to go. If there are opportunities to use slicing syntax, then they would resolve internally to those Expressions I would think. But that can be done separately, and have greater scope such as ArrayField in Simons example. On Friday, 19 January 2018

Re: Security middleware for django for insecure (http) connections

2018-01-16 Thread Josh Smeaton
HTTPS is enough. Despite that, how would you handle the **client** doing decryption and encryption? I don't think this is an idea you should pursue, especially if your expertise is not in security. On Tuesday, 16 January 2018 10:03:00 UTC+11, Vishwas Mittal wrote: > > Hello everyone, > > I am a

Re: Fellow Report — January 12, 2018

2018-01-16 Thread Josh Smeaton
Welcome, and nice work! I've seen some of the reviews you've made and you're straight into the deep end. On Saturday, 13 January 2018 04:01:06 UTC+11, Carlton Gibson wrote: > > Hi all, > > With help from Tim, Aymeric and Frank, I got started on the fellowship > this week. > (Thank you all!) >

Re: Should ModelField.choices accept a callable?

2018-01-11 Thread Josh Smeaton
Migrations are mainly for tracking database changes. Model attributes not SQL related are pushed into the migrations also, presumably for the purposes of data migrations (maybe post-hoc justification, only a few people would actually know). Providing a callable still provides access to the

Should ModelField.choices accept a callable?

2018-01-11 Thread Josh Smeaton
https://code.djangoproject.com/ticket/22837 was closed as invalid. It concerns itself with migrations being detected when model field choices (which may be dynamic) change. The workaround suggested is to pass a callable to choices with a link to https://code.djangoproject.com/ticket/13181.

Re: Change Local Memory Cache to Use LRU #28977

2018-01-11 Thread Josh Smeaton
>> penalty which the LRU-eviction policy will almost certainly improve >> compared with the current random-eviction policy. >> >> Grant >> >> >> On Mon, Jan 8, 2018 at 2:25 PM, Josh Smeaton <josh.s...@gmail.com >> > wrote: >> >>>

Re: Change Local Memory Cache to Use LRU #28977

2018-01-08 Thread Josh Smeaton
ck >> >> >> +1 to adding an option to disable the check as well. If you're using a >> LocMemCache in production, you probably don't care about compatibility with >> memcached, because you'll be using it for different types of data. >> >> On 5 January 2018 at

Re: Change Local Memory Cache to Use LRU #28977

2018-01-04 Thread Josh Smeaton
To lend some weight to this, I've implemented an LRU loc mem cache and have done some benchmarking. There are some graphs in the readme: https://github.com/kogan/django-lrucache-backend - which I've written a little about

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

2018-01-04 Thread Josh Smeaton
I wasn't aware of this new feature Shai, thanks for pointing it out! For this particular case I'd prefer locking to be bound to a particular queryset rather than the database as a whole. I would also expect it to fail loudly when accessing a non-fetched related object (book.author), which can

Re: GLOBAL_PERMS

2017-12-30 Thread Josh Smeaton
> > > - I dislike the seetings approach of GLOBAL_PERMS and would rather see > users writing explicit data migrations. > I don't favour either setting or migration based perms, but if you're going to go with migration based, then please also consider adding a first class permission type,

Re: Improving Backward Compatibility

2017-12-06 Thread Josh Smeaton
the recent releases. > That's one feature per week or fortnight. We'd likely deprecate fewer > features if we had to reach consensus on django-developers every time. > > Best regards, > > -- > Aymeric. > > > > On 7 Dec 2017, at 04:09, Josh Smeaton <josh.smea...

Re: Improving Backward Compatibility

2017-12-06 Thread Josh Smeaton
Following on from Collin, another ticket that generated a large amount of code churn for little perceived benefit was https://code.djangoproject.com/ticket/21127 (enforce on_delete). I know there are many in the community that rail against any and all changes (I had an argument with such a

Re: Additional PostgreSQL-specific functions

2017-12-03 Thread Josh Smeaton
Hey Joey, I think you can create a new ticket for this function. If there is a way to approximate or implement this function in all 4 supported backends then that would be preferred. If it can only really be implemented in postgres, then document in the ticket why, and you can add the new

Re: Feature request: get_first_or_404

2017-11-28 Thread Josh Smeaton
>From my experiences, all projects I've worked on have implemented get_first_or_none and get_first_or_404, and usually slightly differently. I think these shortcuts would make sense for Django. Interested to hear how common the usage would be from others on the list though. -- You received

Re: models.CalculatedField feature

2017-11-19 Thread Josh Smeaton
Introducing an `as_python` to the expression API would probably work. It'd involve a lot of work to implement for all supportable expression types. Considering there are many 3rd party / user code expressions in the wild without as_python, we'd need to find a way to fail gracefully. However,

Re: Using server side cursors for values and values_list

2017-11-18 Thread Josh Smeaton
I can't think of any reasons why not to do this off the top of my head. Have you looked into the code? Is there any technical reason you can see that might prevent chunked fetching from working there? On Saturday, 18 November 2017 03:27:13 UTC+11, Dražen Odobašić wrote: > > Hi, > > at the

Re: [off topic] Re: models.CalculatedField feature

2017-11-18 Thread Josh Smeaton
Re-reading your reply, I think I've misunderstood your intent there (I didn't realise who the author was). Please disregard my previous reply. On Sunday, 19 November 2017 09:59:44 UTC+11, Josh Smeaton wrote: > > Until you want to aggregate or filter on that calculation, and p

Re: [off topic] Re: models.CalculatedField feature

2017-11-18 Thread Josh Smeaton
Until you want to aggregate or filter on that calculation, and perform that filtering in the database rather than pulling back millions of records to do so in python. The database *must* be involved. On Sunday, 19 November 2017 06:32:48 UTC+11, ilya.ka...@jetbrains.com wrote: > > Such

Re: models.CalculatedField feature

2017-11-15 Thread Josh Smeaton
I too have seen computed properties poorly implemented as model functions/properties, only some of the time matched with an appropriate database selector. I think there's a lot of merit in the idea. I don't agree with reimplementing lookups/transforms/funcs to produce the python version of a

Re: Refactoring the autoreloader

2017-10-11 Thread Josh Smeaton
I'd just like to second (or third) an appetite for this or a similar change. Lately I've started to notice very poor performance (high cpu usage, slow shutdowns, etc) with the django dev server on my project. I've moved to runserver_plus/werkzeug with watchdog in the mean time but it'd be good

Re: Having a MongoDB connector for Django

2017-09-11 Thread Josh Smeaton
I'm in agreement with most of the others - that Django should not strive to achieve compatibility with a bunch of different database types simply to open itself up to a larger user base. The cost you pay is a lack of functionality that takes advantage of the specific features granted by a

Custom Join Conditions

2017-08-28 Thread Josh Smeaton
There's currently a patch https://github.com/django/django/pull/7560 for ticket https://code.djangoproject.com/ticket/27332 that implements custom join conditions. It was nearly ready for merge for 1.11 but slipped. There are some merge conflicts the author still needs to sort out, but nothing

Re: Optimizing out unused annotations from count queries

2017-08-19 Thread Josh Smeaton
if the same annotation above works on m2m joins or not. On Sunday, 20 August 2017 09:41:43 UTC+10, Tom Forbes wrote: > > Thanks for your reply Josh. Can you elaborate on why optimizing out ' > .annotate(local=F('related__field'))' would not be safe? > > On 20 Aug 2017 00:10, "J

Re: Optimizing out unused annotations from count queries

2017-08-19 Thread Josh Smeaton
I'd like to see this provided all bases were covered. I'll just list below the cases where I think it wouldn't be safe. - Filtered annotations - Annotations that join to anything other than a non-null foreign key: .annotate(local=F('related__field')) - Annotations that have a GROUP BY on fields

Re: Automatic prefetching in querysets

2017-08-16 Thread Josh Smeaton
I think there's a lot right with your suggestions here Shai. It delivers better default behaviour for new projects, does not affect existing deployments, and seems pretty easy to enable/disable selectively at any level of the stack. My only concern would be libraries leaning on this behaviour

Re: Automatic prefetching in querysets

2017-08-16 Thread Josh Smeaton
> > It won't affect experienced users. They'll read the release notes, see > that this change has been implemented, and either go and delete a bunch of > prefetch_related() calls, grumble a bit and turn auto-prefetch off globally > or just file it away as another fact they know about the

Re: Automatic prefetching in querysets

2017-08-15 Thread Josh Smeaton
I believe we should be optimising for the **common** use case, not expecting everyone to be experts with the ORM. > If I can come up with a single example where it would significantly decrease performance (either memory usage or speed) compared to the default (and I'm sure I can), then I would

Re: Automatic prefetching in querysets

2017-08-15 Thread Josh Smeaton
I'm in favour of *some* automated way of handling these prefetches, whether it's opt-in or opt-out there should be some mechanism for protection. Preferably with loud logging that directs users to the source of the automated hand-holding so they have an opportunity to disable or fine tune the

Re: Admin list view counting

2017-08-08 Thread Josh Smeaton
at. >> > >> > On 7 Aug 2017 08:03, "Adam Johnson" <m...@adamj.eu > >> wrote: >> > >> > +1 from me, I've spent long enough on those COUNT(*) queries at work. >> > >> > Is it worth putting this logic in Paginator so applicat

  1   2   3   4   >