Re: future of QuerySet.extra()?

I've seen *extra()* misused in cases where developers came from a background of writing raw SQL and then used it rather than figuring out the (often relatively simple) ORM way of doing it. This is then a big maintenance burden, and the harsher warning against its use is a good idea. Also

Document/make public prefetch_related_objects

*prefetch_related* is great, but it would be nice to be able to reuse its capabilities with lists of model instances already retrieved by other code (or from cache, or newly constructed, etc.). It seems this is possible by using *django.db.models.query.prefetch_related_objects* which is the

Re: How to disable system check framework?

Marcin - you can "tidy up" some monkey patches, or at least make them robust to the code you're replacing changing, by using https://github.com/adamchainz/patchy . I'm -1 - we've recently been implementing project system checks for our team and they are super useful. We even have one that

Re: Document/make public prefetch_related_objects

ket? > https://code.djangoproject.com/newticket > > On 14 August 2015 at 13:26, Adam Johnson <djcha...@gmail.com> wrote: > >> *prefetch_related* is great, but it would be nice to be able to reuse >> its capabilities with lists of model instances already retrieved by other >>

Re: future of QuerySet.extra()?

something... any suggestions welcome ( https://github.com/adamchainz/django-mysql/pull/144/files ). On Thursday, August 6, 2015 at 10:06:38 PM UTC+1, Adam Johnson wrote: > > I've seen *extra()* misused in cases where developers came from a > background of writing raw SQL and then used it ra

Re: Help needed with the MySQL max index length problem for Django 1.10

This has always been an error on MySQL afaik, it would allow broken data integrity if it were just a warning. Moving the length below 191 does seem to be the safest fix. On Wednesday, December 30, 2015 at 1:52:27 PM UTC, Collin Anderson wrote: > > I think mysql used to just give a warning and

Re: should manage.py test run system checks?

Y'all know my position (original author). How long are the checks taking for people? We have a very large project with >100 models, ~30 apps, and it still takes less than a second. On Thursday, October 22, 2015 at 12:15:59 PM UTC+1, Žan Anderle wrote: > > Adam: I don't think they should be

Re: Deprecate Cache.has_key()?

Might be problematic for third-party cache backends which implement *has_key* and rely on *__contains__* calling it - don't see how you can show the warning in that case. On Saturday, January 30, 2016 at 12:34:14 PM UTC, Tim Graham wrote: > > Yes, but dict.has_key() is removed in Python 3. If

Re: Query on BooleanField with values other than True and False, bug or intentional?

Just to play devil's advocate... you're all worrying about one simple case; there are infinite variants of it with subtle bugs, for example imagine the same situation but with *Value*: Whatever.object.filter(is_active=Value('false')) The ORM can't predict the type of a *Value* call - pretty

Re: View permissions to admin

Hi, At YPlan we've hacked in view permissions to the admin, exactly because of the reasons Markus talked about - it's the front end we've built for employees, done rather than building a proper process-based interface. I think it could just about be done in a third-party package (It might rely

Re: [Question] MySQL Microseconds stripping

Hi, I've just finished converting all the datetime columns to datetime(6) in our database after an upgrade to MySQL 5.6. We don't use Django migrations, many of these were done manually with *pt-online-schema-change*. Just catching up on this thread, throwing some ideas in. Why not strip the

Re: django template modules compiled with cython

Hi guys, I work with Alex here at YPlan. We deployed a tidied updated version of Alex's code as django-speedboost, since it looked promising in local profiling. You can see the code here: https://github.com/YPlan/django-speedboost . It uses a Cythonized version of Django 1.8.8's template

Re: django template modules compiled with cython

quite alpha yet but looks promising: > https://github.com/Microsoft/Pyjion > > El viernes, 5 de febrero de 2016, 13:23:59 (UTC-3), Adam Johnson escribió: >> >> Hi guys, >> >> I work with Alex here at YPlan. We deployed a tidied updated version of >>

Re: [Question] MySQL Microseconds stripping

I've released the forementioned command as part of Django-MySQL, see here: https://django-mysql.readthedocs.org/en/latest/management_commands/fix_datetime_columns.html On Friday, February 5, 2016 at 1:03:42 PM UTC, Adam Johnson wrote: > > Hi, > > I've just finished converting all

Proposal: django.contrib.mysql

The *django.contrib.postgres* docs state: There is no fundamental reason why (for example) a contrib.mysql module > does not exist *Well...* over the past year and a bit I've been developing Django-MySQL. It has a ton of features specific to MySQL and/or MariaDB. For a quick tour of the

Re: Proposal: django.contrib.mysql

o to die” problem. >>> >>> It would obviously help if other community members expressed interest in >>> django.contrib.mysql or, even better, intent to help maintain it in the >>> future. >>> >>> I hope this helps, >>> >>> --

Re: Test projects needed for removal of Field.get_db_prep_lookup()/get_prep_lookup()

Just bumped up against this in Django-MySQL, fixing in django-mysql/pull/292 . In most cases it's easy to work around, but this usecase is not the most fun - wrapping values for the default lookups on the JSONField:

Re: CITextField base class

Sounds legit, make a ticket On 8 February 2017 at 00:37, Sean Brant wrote: > I noticed the new postgres citext[1] field is a subclass of CharField. > Wouldn't it be more correct to subclass TextField? Subclassing CharField > means we need to add a max_length which is

Re: CITextField base class

Pretty sure this is a new ticket since it's effectively a bug report On 8 February 2017 at 11:00, Mads Jensen <m...@inducks.org> wrote: > > > On Wednesday, February 8, 2017 at 11:32:22 AM UTC+1, Adam Johnson wrote: >> >> Sounds legit, make a ticket >> > > S

Re: Removing and renaming Django's Python 2 related helpers

I don't think a deprecation warning is necessary for removing the vendored libraries. The main things that are used are django.utils.six and django.utils.lru_cache which are both easily available separately on PyPI for Python 2/3 compatibility anyway. The warning would probably just make libraries

Re: Renaming the postgresql_psycopg2 backend

For reference the lines doing the fixup in django/db/utils.py: https://github.com/django/django/blob/master/django/db/utils.py#L108 I'm fine with simply removing it rather than putting it through the deprecation process - I don't think subclassing database backends is a big enough usecase, given

Re: changing the default MySQL isolation level to READ COMMITTED

if this fix made it into 1.10" was a typo for > 1.11. Anyway, the "Allowed transaction isolation level to be chosen on > MySQL" commit isn't controversial. I'll try to get at least that in. > > On Friday, January 13, 2017 at 10:11:26 AM UTC-5, Adam Johnson wrote: >> &

Re: changing the default MySQL isolation level to READ COMMITTED

ransaction isolation level to be chosen on > MySQL" commit isn't controversial. I'll try to get at least that in. > > On Friday, January 13, 2017 at 10:11:26 AM UTC-5, Adam Johnson wrote: >> >> aside from some very performance-sensitive websites that already worked &

Re: changing the default MySQL isolation level to READ COMMITTED

(I sent basically the same email twice because it looked to me like the first was lost, didn't even show in my outbox :/) On 23 January 2017 at 21:15, Adam Johnson <m...@adamj.eu> wrote: > Sorry for the radio silence, I've been busy at work. > > After re-reading things and thin

Re: Renaming the postgresql_psycopg2 backend

Ok fair point, I agree it should go through the short deprecation process. It's also very small and not that bothersome to keep around. On 24 January 2017 at 10:46, Josh Smeaton wrote: > I remembered a thing from Michaels talk at #DUTH. Let me present a use > case for

Re: Django 1.11 indexes

Afaik there is no deprecation plan for *db_index*, and I doubt it would be since it would require lots of projects to update their models for no particular gain. Probably best to think of *db_index* as a shortcut for adding an index to *Meta.indexes*. On 28 January 2017 at 21:45, Vitaliy

Re: Modifying django.db.models.expressions.Func.as_sql() to allow `**extra_context` to be more useful

I don't understand the implications of moving the extra_context line, but is it not possible to reverse the order of the params in as_mysql with something like the following? def as_mysql(self, compiler, connection): self.source_expressions = reversed(self.source_expressions) sql, params

Re: Modifying django.db.models.expressions.Func.as_sql() to allow `**extra_context` to be more useful

ng on. If we want to tackle clone performance then we can do so in > another patch. > > > On Monday, 20 February 2017 04:51:18 UTC+11, Adam Johnson wrote: >> >> I don't understand the implications of moving the extra_context line, >> but is it not possible to rev

Re: pull request: write feeds with ordered attributes

I can see the advantage from an operational perspective with files matching byte-for-byte. I know many API's do the same with sorting the keys in their JSON output for the same reason. I should think the performance impact isn't too great, but would be nice to see some benchmarking to prove it's

Re: CITextField base class

I agree with Aymeric that the framework should contain any boilerplate rather than force projects to implement it themselves. On 9 February 2017 at 13:43, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > I’m not a fan of having every project that needs case-insensitive

Re: Model translation and meta options

Sorry for the terrible pun here, but I'd like to suggest the meta-feature... allowing 3rd party apps to add their own options to Meta classes. If there was a sensible API for this (or if Django just copied all attributes defined in Meta onto _meta blindly), Django wouldn't have to add the

Re: pull request: write feeds with ordered attributes

Ok, looks like the second version (conditionally sorting) is the most sensible to go with. On 12 February 2017 at 16:27, Georg Sauthoff <m...@georg.so> wrote: > On Sat, Feb 11, 2017 at 08:15:08PM +0000, Adam Johnson wrote: > > I can see the advantage from an operational perspec

Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

> > Would Django hard code "text/html" as the default? Yes, that's exactly what would happen. Thanks for the bump up, finally added a ticket: https://code.djangoproject.com/ticket/27829 On 12 February 2017 at 07:28, Brian May wrote: > On Friday, 13 January

Re: Should Model.save() fix incorrect types that happen to save correctly?

> > What do you think? Absent a better suggestion, we could document this > pitfall so that there's something to point to when related tickets come in. +1, as Aymeric points out the more complex fields probably won't work with coercion-on-set. On 13 February 2017 at 15:27, charettes

Re: Check if dependencies are up to date

ndle_post, command='runserver') > > I believe this also can be used by Django itself as there are some cases > where contrib apps override core command functionality (I believe this > happens for staticfiles app overriding runserver) > > Should I create a ticket about it? > > --

Re: Check if dependencies are up to date

need to install it. For us this boils down to a vagrant provision, so that's what the message says. I agree, requires.io is a nice service for this. On 16 January 2017 at 14:18, James Bennett <ubernost...@gmail.com> wrote: > On Mon, Jan 16, 2017 at 4:47 AM, Adam Johnson <m...@ada

Re: Check if dependencies are up to date

Hi Mathieu, We implemented something similar at YPlan but discovered that it wasn't a good idea as a system check, because if a dependency changes from another devs work then often Django can't even start and run the system check. Especially a problem when upgrading Django itself! Instead we

Re: RedirectView failing silently on NoReverseMatch is confusing

I can't see any rationale for it on the ticket, PR, or mailing list discussion . The original implementation in the PR actually raised

Re: Adding Support for a Float32 Field

> > Personally I do not see much need for it in core. Same, it's not hard to implement as a custom field in a third party plugin. Another point is that this isn't supported by SQLite - it only has "REAL" meaning a double precision. On 26 February 2017 at 16:21, Florian Apolloner

Re: Window expressions, #26608

I'm not sure about that detail atm, I need to review the patch. I just think we shouldn't be putting anything in postgres-only land. On 29 November 2016 at 22:04, Josh Smeaton wrote: > Adam, are you thinking we should be adding something like > Model.objects.window(), or

Re: Window expressions, #26608

As to your point 1: > Since this is specific to postgres Well, Window expressions aren't specific to Postgres: - They exist in Oracle - They exist in MariaDB 10.2 which is in beta and will be GA at around the same time this patch is out:

Re: Guidelines to name python modules of Django applications?

+1 (to what Aymeric and Florian said) On 7 December 2016 at 19:54, Robert Roskam wrote: > +1 > > On Wednesday, December 7, 2016 at 11:25:05 AM UTC-5, Marc Tamlyn wrote: >> >> What Aymeric and Florian sayid. >> >> On 7 December 2016 at 15:58, Florian Apolloner

Re: GeoDjango OffdbRasterField

I can't say I'm that familiar with GeoDjango, but that does sound like a useful feature. Where does the data get stored if not in the DB? And does this feature exist on any of the other database backends that GeoDjango supports? On 14 December 2016 at 18:40, Piero Toffanin

Re: Please help me with "Writing your first patch for Django"

Also you might be experiencing failures specific to your operating system and database setup - if you'd paste the stack traces we might be able to figure more out. On Sat, 17 Dec 2016 at 16:27, Tim Graham wrote: > 1. As the tutorial says, "Some tests are specific to a

Re: Removing aliased imports ("from") in generated migration files to prevent conflicts

There's a 6th way, which is to alias the probematic modules rather than django's modules, e.g. from django.db import models import models as models_ ... Field( default=models_.my_default ) ... There's also a 7th way, which is to use flake8 which will, with its default config, complain

Re: Django sum and filter does not work

Hi, You've reached the Django Developers list, the list we use for people who are working on Django itself. The list for asking questions about using Django is Django Users, at https://groups.google.com/forum/#!forum/django-users . Thanks, Adam On 12 January 2017 at 21:42, dheeraj saini

Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

Having reviewed the ticket a bit and thought about it, I've had two thoughts: 1. The current patch doesn't fix existing custom views which the docs explain how to use, and I've seen used quite often.

Re: SubQuery without using RawSQL

I vote for Subquery - I wouldn't make a class called SubTitle  Also SubQuery somewhat implies it's a subclass of Query. I think Josh has been staring at Query for too long  On 12 January 2017 at 12:30, Tim Graham wrote: > A question about the casing. Since "subquery" is

Re: changing the default MySQL isolation level to READ COMMITTED

> > aside from some very performance-sensitive websites that already worked > around Django’s bugs Tbf it's true I already added READ-COMMITTED at work I’d love if this fix made it into 1.10 On 13 January 2017 at 15:05, Aymeric Augustin < aymeric.augustin.2...@polytechnique.org> wrote:

Re: Admin changelist turns QueryDict into dict

I suspect it was simply to make it easier to work with. I'd suggest you create a ticket at https://code.djangoproject.com/newticket and then try making the change and seeing if Django's test suite still passes. All the information you should need is at

Re: Use of HTML autofocus attribute in admin (#27692)

I think we should remove it and maybe add the Javascript back, this is going to affect many peoples' workflows, some of whom are in my organization. On Friday, January 6, 2017 at 5:48:12 PM UTC, Tim Graham wrote: > > As part of removing inline JavaScript in the admin [0], snippets such as >

Re: Working towards a simpler GCBV implementation?

I think this is probably too disruptive a change for Django core, especially after so long with the current GCBV implementations - it would require all users to rewrite their CBV's. Possibly the documentation could recommend django-vanilla-views? On 3 January 2017 at 13:02, Asif Saifuddin

Re: Methodology for increasing the number of PBKDF2 iterations

> > But, to be consistent with Django 1.x going forward, let's define 36,000 > iterations as "acceptable performance" for a Python2 with Django 1.11 > install on a typical piece of server hardware today (beginning of 2017). A > useful benchmark would be to determine how many iterations would yield

Re: django-formtools is neglected/unmaintained

1) Tim added testing on Django 1.10 in July 2016, it seems to work? https://github.com/django/django-formtools/commits/master 2) New contributors are always welcome 3) I don't know of other packages, you can check https://djangopackages.org/ 4) It's true that many websites are built with pure JS

Re: Changing {% include %} to strip a trailing newline

ption is probably necessary for some more > > advanced uses of templates out there, e.g. templating whitespace > > sensitive file formats." -- I'm not following why a similar find/replace > approach wouldn't be sufficient to adapt those templates? > > > On Wednesday, Jan

Re: Changing {% include %} to strip a trailing newline

ong >> distaste for anything more complicated. >> >> Best regards, >> >> -- >> Aymeric. >> >> On 4 Jan 2017, at 20:58, Tim Graham <timog...@gmail.com> wrote: >> >> Shortly after template widget rendering was merged, an issue abo

Re: Add custom autoreload file tracking options setting

> > How do people serve development Javascript & CSS files? These days > Javascript & CSS involves a large build process. Are we forced to manually > restart the development server every time Javascript changes? Django just serves them from the filesystem, and doesn't cache them itself. You

Re: [Feature request] Template language type annotations (#27703)

I think a third party implementation could be done first for the separate tag. I also think you'd learn more and iterate faster by building some tooling on top of the tags whilst a third party app before merging with core was considered. One idea that springs to mind is allowing multiple type

Re: Responsive admin

> > - perhaps supplying an empty CSS file with the same name overrides the > file provided by the admin? (I’m not sure) It does, as long as the app it's in is before django.contrib.admin in INSTALLED_APPS, django-grappelli uses this mechanism

Re: Should we add a dependency on the multipledispatch library, or vendor it?

I agree, it doesn't seem likely there will be breaking changes in it either. According to DEP007 ( https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst ), dependencies should go through on the feature DEP rather than just via the mailing list. And btw was

Re: MariaDB, official support

Hi, Sorry I missed this thread! Adam is (or is planning..) writing a DB backend that includes MySQL and > MariaDB > Not technically, I'm actually writing a backend to use the newer MySQL DBAPI library pymysql at https://github.com/adamchainz/django-pymysql-backend . For the first pass at

Re: Methodology for increasing the number of PBKDF2 iterations

Thanks Alex, TIL https://mail.python.org/pipermail/distutils-sig/2016-May/028986.html On 4 January 2017 at 17:42, Alex Gaynor wrote: > Python 2.7.12 will look the same as 3.5.x, they both have the optimized > implementation. Only 2.7.X where X<8 will have the slow

Re: Working towards a simpler GCBV implementation?

:30:54 AM UTC-5, Asif Saifuddin wrote: >> >> Hi, >> >> I will update the doc pointing vanilla views as simpler alternative >> implementation. >> >> Thanks >> >> On Tuesday, January 3, 2017 at 7:20:24 PM UTC+6, Adam Johnson wrote: >>>

Re: Add custom autoreload file tracking options setting

For that use case I'd suggest just re-executing prepare_db_queries on every page view when DEBUG=True. This is similar to how Django's template loaders work without the cached loader wrapping them. On 4 January 2017 at 21:12, Bobby Mozumder wrote: > OK here is some example

Re: Use of HTML autofocus attribute in admin (#27692)

; my request though, I'd still like the autofocus to be either removed or > optional. > > Op vrijdag 6 januari 2017 18:54:54 UTC+1 schreef Adam Johnson: >> >> I think we should remove it and maybe add the Javascript back, this is >> going to affect many peoples' workflows, some

Re: Template handling of undefined variables

> > I apologise if adding the tests has made it harder to improve the > behaviour of the tag. I don't think you have anything to apologise for! More tests is always better. This has clarified the current behaviour  On 6 January 2017 at 10:15, Alasdair Nicol wrote: >

Re: Considering removing support for ("iLmsu") regex groups in URLpatterns. Do you use them?

Since they were used in several places in Django's test suite I feel like it's highly likely they're out there in use in the wild. Also if Django were to remove it, it would both 1) be a bit surprising compared to the re module, as it's an implementation detail that the urlparser prefixes '^/'

Re: Please help me with "Writing your first patch for Django"

> > That appears to be the full stack trace since it errors out in the assert >> :D > > Oh yes, my bad, I'm used to pytest ;) > On Sunday, December 18, 2016 at 2:15:54 PM UTC, Florian Apolloner wrote: > > > > On Saturday, December 17, 2016 at 7:08:23 PM UTC+1, A

Re: Considering removing support for ("iLmsu") regex groups in URLpatterns. Do you use them?

I think the current implementation means they affect all included children. On 20 December 2016 at 07:15, Sjoerd Job Postmus <sjoerd...@sjec.nl> wrote: > On Mon, Dec 19, 2016 at 08:23:09AM +0000, Adam Johnson wrote: > > > > > > I guess the "safest" opti

Re: Considering removing support for ("iLmsu") regex groups in URLpatterns. Do you use them?

uding a newline; without this flag, '.' will match anything except > a newline. > > re.U -- Unicode -- these are redundant in Python 3 since matches are > Unicode by default for strings > > On Sunday, December 18, 2016 at 4:18:33 PM UTC-5, Adam Johnson wrote: >> >&g

Re: Adding UNION/INTERSECT/EXCEPT to the ORM

Yes it's different, they cannot be changed due to backwards compatibility issues. They don't result in UNION in SQL, they union the filters on two querysets that are on the same exact model. On 26 December 2016 at 21:00, Cristiano Coelho wrote: > Is this going to be

Re: #26369: default formfield callback override

Oh, I misunderstood, I thought you controlled both the models and forms but wanted to enforce consistency. If you don't control the models (like FlatPage), I presume you control the forms then?You can do it then with a custom ModelForm subclass that overrides some of the building behaviour.

Re: No 'Content-Type' header in response

Hi GMail! (you might want to fix your name used on google groups, I had the same problem ;) ) This seems to be a legitimate bug in the __repr__ to me - SO informs me that DRF is correct in not defining a Content-Type for a 204 as it has no body:

Re: What is the contract of a cache backend regarding errors?

Hi Jean, I wrote a cache backend for MySQL in Django-MySQL and didn't add any special error handling. Like the builtin database cache backend, it uses the same connection as the ORM, so if an error does occur it's pretty likely the whole request is broken anyway. If you look at the code,

Re: #26369: default formfield callback override

I've thought a bit more about this, and have had three ideas: 1. The signal idea doesn't seem likely to work in all cases due to import order considerations. Forms can easily be imported during Django startup whilst models, views, or urls, are imported, before AppConfig.ready() is fired, which is

Re: Should SECRET_KEY be allowed to be bytes?

+1 to what Aymeric wrote. I was just drafting an email with a similar argument about how it's hard to manage pure bytes in config management systems that write to env vars, that's why ascii strings are so useful. They're also easy to copy/paste and verify when adding them to your config

Re: Feature request: django.py makemessages --add-location=full|file|never

I don't see any reason against adding it. If there isn't a ticket already, you can make one at https://code.djangoproject.com/ , then look at the extensive contributing guide . On 27 March 2017 at 19:26,

Re: To keep or not to keep: logging of undefined template variables

Doesn't sound like there's much impetus either way, and it's confusing people, so I'd say remove it. Or maybe make it optional, default off? On 19 March 2017 at 07:52, Tim Martin wrote: > I don't have any objection to removing this. However, the thought occurs > that my

Re: I would like to discuss my proposal for a working way to call .add() on an m2m with through= model

It does seem like a somewhat arbitrary historical restriction. Collin's PoC change is surprisingly small and simple. Seems like it would be fine if Django allowed add() and let any errors > about missing data bubble-up. > Agree, this is also a precedent from get_or_create. > I personally think

Re: Any interest in integrating Django Admin Sortable into core?

Hi Brandon, Thanks for offering to contribute. I'm not particularly familiar with the admin but from a quick look I see django-admin-sortable uses jQuery UI to support its functionality, whilst contrib.admin doesn't use it. I don't think there's a strict policy on whether new JS libraries should

Re: Adding generated common table expressions

> > supported is added in MySQL 8 [0] > Additionally MariaDB 10.2 supports them, and it's nearing release. On 18 March 2017 at 07:59, Matthias Kestenholz wrote: > Hi, > > On Sat, Mar 18, 2017 at 12:49 AM, Tim Graham wrote: > > Hi, I don't know anything

Re: Add ability to choose a different secret for PasswordResetToken

Presumably you mean PasswordResetTokenGenerator when you write PasswordResetToken. Seems like a fairly small feature, but my security sense is tingling when you say you're putting the secret key of one application in a variable for another. Normally in a situation where multiple applications

Provide 'V' as alias for 'Value'?

When writing filter expressions using database functions, one is often forced to use django.db.models.Value to wrap raw values to avoid them being interpreted as column references. Value is fairly cumbersome to write when it can appear several times in a complex queryset definition, so it's common

Re: DJANGO_SETTINGS_FILE

You could do this already by putting a file on PYTHONPATH that just reads the contents of the file specified by DJANGO_SETTINGS_FILE and puts it in its own module dict, e.g. $ cat ~/tmp/test.py foobar = 12 $ TEST_SETTINGS_FILE=~/tmp/test.py ipython ... In [1]: import imp, os In [2]: test =

Re: assertRaises vs. assertRaisesMessage

I agree with Tim. He's also probably the most familiar with the cost of message changes  On 7 April 2017 at 12:56, Tim Graham wrote: > Hi Shai, > > Without testing for a message, there's also a possibility that the > exception you think you're testing isn't the one the

Re: Making __repr__ safe by default

Patryk, when you say 'revisit', do you have links to the original discussion/tickets? I also agree that __repr__ shouldn't be able to trigger extra DB queries in a standard setup. On 7 April 2017 at 13:18, wrote: > I'd like to support this, I've seen my share of situations

Re: assertRaises vs. assertRaisesMessage

That said more structured attributes on exceptions can be useful for Django users, if you know any obvious places they are missing. On 7 April 2017 at 13:23, Adam Johnson <m...@adamj.eu> wrote: > I agree with Tim. He's also probably the most familiar with the cost of > message change

Re: proposal: add special subclass of ForeignKey for storing ContentTypes

Sergey, I like the idea. It at least serves as a demonstration of what can be done with custom fields. The PoC shows it's not too much code either. Would you be looking to replace the existing FK's to ContentType too, e.g. in Admin and Auth? On 5 April 2017 at 06:24, Asif Saifuddin

Re: #26369: default formfield callback override

> > About 1, if it's already working with a non-signal, how could it not work > with a signal ? It is, after all, called from within formfield() in this > implementation, so anything that's working today when formfield() is > called, should work when formfield() emits a signal. > Signal handlers

Re: Ticket 28087: Allow filtering and ordering with RawQuerySet

I'm worried this doesn't work in the general case, as there are a lot of different query formats one can write with raw SQL, such as UNION, SQL variables, or other database specific formats. You have a lot of code there, but from what I can tell the code is simply setting up the RawSqlCompiler

Re: Ticket 28087: Allow filtering and ordering with RawQuerySet

ilerequisites ' > 'ON isp_finances_profilerequisites.profile_id = isp_user_profile.user_id ' > 'JOIN auth_user ' > 'ON auth_user.id = isp_user_profile.user_id ' > > > Is such RAW query (with working pagination and sorting) possible to > convert to model manager QuerySet query? > > On Frid

Re: Ticket 28087: Allow filtering and ordering with RawQuerySet

n Friday, April 21, 2017 at 1:40:47 PM UTC+3, Adam Johnson wrote: >> >> Joining two tables like that on one-to-one relations can be easily >> achieved with select_related >> <https://docs.djangoproject.com/en/1.11/ref/models/querysets/#select-related> >> . &

Re: Database "execute hooks" for instrumentation

django-perf-rec would love this, it currently monkey patches connection.ops.last_executed_query to listen to all the queries going on. On 7 April 2017 at 16:10, Shai Berger wrote: > On Friday 07 April 2017 17:47:51 Carl Meyer wrote:

Re: DJANGO_SETTINGS_FILE

I implemented this based upon the code snippet I showed in my first reply. Anyone who wishes to use DJANGO_SETTINGS_FILE can now pip install django-settings-file and follow its setup instructions: https://pypi.python.org/pypi/django-settings-file I've added some caveats I thought of during

Re: Ticket 28087: Allow filtering and ordering with RawQuerySet

а > реквизиты') > requisites_object = GenericForeignKey('requisites_type', 'requisites_id') > is_preferred_withdrawal = models.NullBooleanField(default=None, > verbose_name='Предпочтительный способ вывода') > > > On Friday, April 21, 2017 at 7:55:31 PM UTC+3, Adam Johnson wrote: &g

Re: Database connection retry

Chris, whilst I'm sure you could work something out, it probably wouldn't generally work as database connections contain a lot of state, such whether or not we're in a transaction and variables. On 8 March 2017 at 20:23, Chris Foresman wrote: > I'll chime in to say I've had

Re: Problem with running tests with mysql database.

For the lock wait timeout errors, it's probable something (another test run?) is still connected to the database and holding the locks. Try restarting mysql. And if you are still having problems, knowing the version of MySQL you're using, plus how you installed it, would be helpful. On 10 March

Re: Commitable json dumps

PyYAML sorts keys by default, so if you use the YAML serializer that should work for your usecase. I think patching the JSON serializer to be deterministic by default is a good idea, the performance cost of sorting keys is pretty small compared to disk operations. On 6 March 2017 at 11:32, Brice

Re: Commitable json dumps

Wait, I just looked into this further, and discovered that the ordering of fields was made deterministic for all serializers in #24558 <https://code.djangoproject.com/ticket/24558> - this was released in Django 1.9! Enjoy On 7 March 2017 at 22:23, Adam Johnson <m...@adamj.eu> wrot

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

Personally I'd be in favour of adding such classes. It seems against the batteries-included philosophy that Django does not provide all of the standard codes as classes. I can never remember which codes correspond to which response types, if I saw status=204 in code it would be a 'magic number'

  1   2   3   4   5   6   7   8   9   10   >