Re: GitHub migration done!

I wrote a little userscript that linkifies ticket numbers in github pull request to the correct trac ticket. It can be found here . Le vendredi 27 avril 2012 23:08:09 UTC-4, Adrian Holovaty a écrit : > > On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty

Re: Multi-tenant Django

Using django-hosts I managed to put together a simple setup that maps subdomains to databases. First, I have a default database with a table mapping sudomains to database name and a middleware that tries to load the correct object based on the match provided by django-hosts. In my settings I

Re: Multi-tenant Django

The "migrating models on every database issue" can be solved easily by creating a command that calls the specified one using `call_command` and passing the correct `db` kwarg to the underlying one. Say you have installed South and want to call the `migrate` with two underlying dbs.

Re: Changing INSTALLED_APPS before syncdb on the fly

This list is for Django development only, please refer to the django-user list to get support in the future. Take a look at database routers and the `allow_syncdb`[1] method to achieve that. Simon [1] https://docs.djangoproject.com/en/1.4/topics/db/multi-db/#allow_syncdb Le mercredi 4

Re: When to close pull requests

FYI I wrote a small userscript[1] (greasemonkey) that linkify ticket number when browsing github.com/django/django. It's quite useful when reading the source from the web interface since tickets referenced in python comments are just a click away. [1] https://gist.github.com/2528393 Le

Re: Model equality in inheritance cases

#11154 is really about another issue; it has nothing to do with model equality. I'll try to submit a new patch with a release not in the next days as requested by anssi. Le lundi 16 juillet 2012 17:44:06 UTC-4, Daniel Sokolowski a écrit : > > I would also throw this ticket into the mix - >

Re: Python 3 - style question

I think this will only be an issue for django application maintainers. IMHO, projects target a specific version of python and won't have to provide python 2-3 compatibility. Am I wrong? Le jeudi 9 août 2012 16:36:12 UTC-4, Aymeric Augustin a écrit : > > Hello, > > One of the first lessons in

Re: Help review tickets, get a prize!

What do you guys think of mentioning this in the Triaging ticketsdocumentation? Should I open a ticket? Le mercredi 20 avril 2011 17:25:58 UTC-4, Jacob Kaplan-Moss a écrit : > > Hi folks -- > > We have a chronic

Re: Testing django 1.5 with firebirdsql

Here's the topic you were referring to Anssi. https://groups.google.com/forum/#!topic/django-developers/AZrSn6LCLVU/discussion Le samedi 15 septembre 2012 13:18:38 UTC-4, Anssi Kääriäinen a écrit : > > On 15 syys, 01:05, maxi wrote: > > BTW, I've another issue related to

Re: Next steps for ticket #18150

It looks like the appropriate module to add the test. The next step is to upload you patch with the test to #18150to get it reviewed. Simon Le dimanche 3 février 2013 17:26:29 UTC-5, Steven Vargas a écrit : > > Hi, back again. I wrote a test for

Re: 'Change' button for related fields.

There's already tickets for this feature request #13163<https://code.djangoproject.com/ticket/13163>and # 13165 <https://code.djangoproject.com/ticket/13165>. I've been planning to propose a patch based on django-admin-enhancer<https://github.com/charettes/django-admin-enhancer&g

Ticket #15363 -- Normalization of the queryset methods name

Since the consensus as shifted toward not making a break-everything 2.0 I'm planning to normalize the queryset methods name early in the 1.6 development cycle to spot any breakages. The affected classes are the following: - *django.contrib.admin.options.BaseModelAdmin* (*queryset* -­>

Re: model query get_or_create() thread safety and uniqueness -- proposal for transactional commit before final get

There was a discussion on the subject here . Le jeudi 4 avril 2013 23:23:43 UTC-4, Matteius a écrit : > > > Greetings Developers, > > Today at work I fixed a thread safety issue in our code whereby two > threads were

Re: Request: Ability to add new databases dynamically.

If you're using PostgreSQL you could try creating a schema for each tenant. That's what django-tenancy <https://github.com/charettes/django-tenancy>does internally. You define which models are *tenant specific* by subclassing *TenantModel* and then you create instances of* Tenant* (o

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

This makes me wonder if you're planing to introduce a `SOUTH_TEST_MIGRATE` setting analog when moving migration handling to core. I think most people with a huge south migration history will set this setting to `False` to speedup testsuite execution and thus they couldn't be used for database

Re: Supported Python versions for Django 1.7

If we drop support for Python 2.6 in Django 1.7 we should document that 1.6 will be the last version to support and announce it on the next beta/candidate release. Le vendredi 28 juin 2013 10:17:22 UTC-4, Aymeric Augustin a écrit : > > Hello, > > We just forked the stable/1.6.x branch. The

Re: More input on #20945

Don't know if my last message made it to the mailing list, it looks like google-group might have eaten it. If it's not the case sorry for the noise. Concerning (2) I do agree with Carl it's not required to default to a specific template fragment cache alias. For the uncommon cases you want to

Re: Benchmarking 1.5 vs 1.6

I guess it's related to a2396a4c8f[1] and #19184[2]. [1] https://github.com/django/django/commit/a2396a4c8f2ccd7f91adee6d8c2e9c31f13f0e3f [2] https://code.djangoproject.com/ticket/19184 Le dimanche 15 septembre 2013 20:05:43 UTC-4, Curtis Maloney a écrit : > > So what's going on here: > >

Re: changing the on_delete=CASCADE default

I think it would make a lot of sense to require an explicit `on_delete` when a ForeignKey is nullable because of the ambiguity concerns raised on Trac. However I'm not convinced this should be required for non-nullable ones since, IMHO, CASCADE is the most sensible default in this case. Le jeudi

Re: Custom Users + Signals (reusable app)

It is possible to attach signals to `settings.AUTH_USER_MODEL` while taking its swappable nature into account. There might be a better way but that's how I've done it for a reusable application of mine<https://github.com/charettes/django-tenancy/blob/d6d63af092439a6f66a56ff490efb1f358c02

Re: Custom Users + Signals (reusable app)

Here's a POC<https://github.com/charettes/django/compare/lazy-class-prepared>which passes all tests on Py2 SQLite. Le mardi 29 octobre 2013 23:10:39 UTC-4, charettes a écrit : > > It is possible to attach signals to `settings.AUTH_USER_MODEL` while > taking its swappable natu

Re: How to livereload Django templates?

Hi Nikolay, You could implement such a feature as a third party app by connecting a receiver to the template_renderedsignal. I suggest you take a look at how django-debug-toolbar tracks which template were

Re: Registering signal handlers

Since Django 1.7 you can lazily reference model signal sender, it might help solving your circular import issues. It seems providing a reliable initialization signal is one of Aymeric's main goal. Simon Le dimanche 22 décembre 2013 03:22:29 UTC-5, Curtis Maloney a écrit : > > Reading the

Re: Django explicit `order_by` by ForeignKey field

After discussion this was escalated to a release blocker in order to make sure we don't miss the opportunity of fixing it correctly. I attached a patch to the ticket that makes sure that explicitly ordering by a relation source field (group_id in your case) produces the expected result. Simon

Re: Updating the organization of the Django Project

+1 Thanks for putting this up together Aymeric Simon Le mercredi 23 juillet 2014 09:30:13 UTC-4, Aymeric Augustin a écrit : > > Hello, > > I’ve been working on updating our organization: > https://github.com/django/django/pull/2947 > > This proposal attempts to address several issues with

Re: pre_save signal on Inherited Model?

This might be related to #9318 . Le mardi 19 août 2014 20:48:07 UTC-4, Leo Hillman a écrit : > > I just wanted to write a preliminary post about this before gathering a > little more data. When extending a non-abstract model (Python inheritance) > it

to_field_allowed regressions

As some of you might have noticed the initial patch to prevent data leakage in contrib.admin via query string manipulation[1] introduced many regressions[2][3][4] that resulted in two security releases so far. The actual implementations does four checks to ensure a field is allowed to be

Re: resurrecting an old friend, whitespace in forms, #6362

Like Russ I think this should be at the form level. Since both db.CharField and db.TextField use a form.CharField the stripping implementation should be done there. I commented here because I recently fixed a related bug in an application I maintain where a trailing white-space was not striped

Re: enum fields in django

> I try to keep myself out of philosophical arguments. Reference tables > have a purpose (when you're dealing with a set of values that aren't > fully known when you're defining the dataset (eg. custom application > error code tables)), but when the dataset _is_ known in advance an > enum

Re: Password validation in Django revisited

Hi Erik, This looks promising. I like how the validators can be chained and the whole simplicity of the patch. Here's some comments I also left on the PR; 1. I think the settings should be name AUTH_PASSWORD_VALIDATORS since it's being use by the auth contrib app; 2. I would avoid

Re: Custom Model field, to_python() / from_db_value() and unittests...

Hi Jens, I'm not sure I understand what you are trying to achieve but I assume you want to write a third-party field that supports both Django 1.7 and 1.8 without raising deprecating warnings? I suggest you use the following pattern which also accounts for py2/3: import django from django.db

Re: Why Django is making migrations for external apps?

Hi everyone, Here's just an idea from the top of my head. What if we exposed a `django.db.migrations.Reference` that would be a deconstructible proxy to a top level module object. It would be initialized with a module name string and the referenced object name as a second argument. We could

Re: Why Django is making migrations for external apps?

d > with the current model, I don't see a need to maintain its presence or > value in migrations. > > /Markus > > On July 17, 2015 11:46:15 AM GMT+10:00, charettes <chare...@gmail.com > > wrote: > >Hi everyone, > > > >Here's just an

Re: Django 1.8 has an undocumented change regarding template comments

Hi Robert, I don't exactly know which release introduced this change but I'd bet on 1.8.0 since a lot template related logic was refactored during its development. If you want to isolate the exact commit I'd suggest you try bisecting [1] Django's source. I think the change was unintentional

Re: Why is from_db_value not called on ModelClass.objects.create()?

Hi Gordon, That's what I would expect the cash attribute to be since it was not retrieved from the database but explicit set during initialization. To me the `from_db_value` method name makes it clear it is only called in the former case. If you want the object you created to have a certain

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

Hi David! As Josh said it's great to see another contributor interested in the ORM. There was a recent discussion on this mailing list about an ORM query syntax enhancement[1] that you might find interesting. From what I remember there was a proposal similar to yours. Simon [1]

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Hi Reid, 2.0 is not planned to be a special release in regard to backward compatibility. Since this is a backward incompatible change (what should be done with duplicate usernames, etc.) I doubt it's going to happen. Simon Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit : > >

Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

Hi everyone I'm the author of this change. I'm not a big fan of the model validation layer myself but I assumed basing a model level check on it would make sense. I was not aware there was such a bad feeling about the model level validation, if I had I wouldn't have based this check on it. It

Re: a standard descriptor signature?

Now that Curtis did all the investigation work I think it wouldn't hurt being consistent here. __get__(self, instance, cls=None) and __set__(self, instance, value) look like sane defaults to me. Le samedi 24 octobre 2015 18:36:32 UTC-4, Tim Graham a écrit : > > Curtis, or should I say

Re: Useless locmem pickling?

Hi Bertrand, One reason I see for the locmem cache to pickles the data is stores would be to prevent mutable objects from being shared between threads. e.g. Thread one stores [1,2,3] as 'foo', keeps a reference to it to alter it. Thread two gets 'foo' and alters it. And to prevent memory

Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

October 2015 04:13:47 charettes wrote: > > Hi everyone I'm the author of this change. > > > > I submitted a PR (https://github.com/django/django/pull/5471) to > completely > > revert this change given suggest adjustments don't get enough support. > > >

Re: feature request - use logging in WSGIRequestHandler

FWI a new ticket[1] with what looks like a sane implementation to add this level of logging to the runserver command has been created. I'll make sure to copy all the concerns raised by Russ over there and you might want to chime in the review process. Simon [1]

Re: Provide a way to pass kwargs when initializing the storage class

I think the proposed approach makes sense. I don't think we need to support any variant to pass the configuration values as args. All the existing storage backends have to make their argument optionals anyway now to support how they are currently initialized. Requiring a dict makes it also

Re: Provide a way to pass kwargs when initializing the storage class

I think the proposed approach makes sense. I don't think we need to support any variant to pass the configuration values as args. All the existing storage backends have to make their argument optionals anyway now to support how they are currently initialized. Requiring a dict makes it also

Re: [Question] Many-To-Many query where only pk is returned

Hi Cristiano, If I get it correctly you'd like m2m querying to start with the intermediary (FROM) table and JOIN the referenced one only if more fields than the primary key are selected. class Book(models.Model): name = models.CharField(max_length=100) class Author(models.Model):

Re: [Question] Many-To-Many query where only pk is returned

y help > just a few people, as only fetching data from the intermediary table is a > rare thing. But if it is an easy change, which improves performance, why > not? However I think the change is quite complicated. > > El jueves, 19 de noviembre de 2015, 11:51:51 (UTC-3), charett

Re: Backporting ticket 25548 into 1.9.x

I confirm this is the reason it wasn't backported in the first place. Le lundi 7 décembre 2015 08:20:19 UTC-5, Tim Graham a écrit : > > I've done the backport. I think the only reason it wasn't done initially > is that there's no indication on the ticket that the issue was a regression. > > On

Lazy operations refactor regression with abstract models #25858

During the refactor of lazy operations[1] abstract models stopped resolving their related field model reference by themselves[2][3] in order to prevent pending lookup pollution. This was necessary in order to warn the users about unresolved relationships in a reliable way. This change introduced

Re: slow migrations

Shai, I think I have a viable solution for the the second kind of data migration your are mentioning. https://code.djangoproject.com/ticket/26064#ticket Simon Le samedi 9 janvier 2016 11:30:01 UTC-5, Shai Berger a écrit : > > On Saturday 09 January 2016 04:56:11 'Hugo Osvaldo Barrera' via

Re: Lazy operations refactor regression with abstract models #25858

Thanks for your input everyone. You convinced me we should with the third option[1] for now. Markus, nothing prevent us from changing this behavior in the future if there's a need for it but since this is a regression and we don't have a clear backward compatible upgrade path defined we should

Re: db.models.options help with a piece of code analysis.

Hi Elton, >From a quick look this branch seems to handle attributes inherited from possible `Meta` bases. e.g. class Foo(models.Model): class Meta: app_label = 'app' class Bar(models.Model): class Meta(Foo.Meta): pass assert 'app_label' not in Bar.Meta.__dict__ assert

Re: db.models.options help with a piece of code analysis.

ton Pereira de Lima a écrit : > > Hello charettes! > > Analyzing the code further, I saw that it was impossible for the Bar Meta > class inherits from Foo.Meta because when this code > <https://github.com/django/django/blob/master/django/db/models/base.py#L108> > is executed,

Re: db.models.options help with a piece of code analysis.

FWIW, as Marteen pointed out, the `Meta` attribute is only available on abstract classes because of these lines <https://github.com/django/django/blob/5c048f95cc4a988a35bfd94655469310830a2cf8/django/db/models/base.py#L274-L280> . Simon Le lundi 18 janvier 2016 13:09:16 UTC-5, charettes a

Re: Making QuerySets composable

Hi Patryk, > Currently we have Prefetch objects that kind of solve this problem for M2M > relations but perhaps it would be nice to also be able to use QuerySets in > select_related() or even in filter(). I don't think Prefetch objects are best > suited for that and I personally find having to

Re: test --keepdb and explicitly migrating the test database

FWIW I've been working around this limitation by adding a suffix to my `DATABASES['alias']['TEST']['NAME']` setting if the project VCS branch is not the default one. e.g. for Git import subprocess branch = subprocess.check_output(['git', 'rev-parse', '--abbrev-ref', 'HEAD']).strip() if branch

Re: remove support for unsalted password hashers?

> That hasher, being the fastest non-plaintext hasher around, is quite useful > when running tests: it allows login checks to be performed much faster. This argument came up a couple of time in the past and from what I remember the Django test suite itself spends a significant amount of time

Re: remove support for unsalted password hashers?

Tests that verify the password hasher will need to run the hash algorithm > regardless. I'm aware of that but this only represents a small fraction of the tests. Le mardi 2 février 2016 13:49:31 UTC-5, Jon Dufresne a écrit : > > On Tue, Feb 2, 2016 at 10:35 AM, charettes <chare...@gmail.com

Re: remove support for unsalted password hashers?

Tests that verify the password hasher will need to run the hash algorithm > regardless. I'm aware of that but this only represents a small fraction of the tests. Le mardi 2 février 2016 13:49:31 UTC-5, Jon Dufresne a écrit : > > On Tue, Feb 2, 2016 at 10:35 AM, charettes <chare...@gmail.com

Re: Lazy operations refactor regression with abstract models #25858

[4] https://code.djangoproject.com/ticket/24215 Le vendredi 8 janvier 2016 16:16:33 UTC-5, charettes a écrit : > > During the refactor of lazy operations[1] abstract models stopped resolving > their related field model reference by themselves[2][3] in order to prevent > pe

Re: Lazy operations refactor regression with abstract models #25858

convoluted before the lazy operations refactor. Simon Le mercredi 10 février 2016 16:11:43 UTC-5, Shai Berger a écrit : > > On Tuesday 09 February 2016 23:33:50 charettes wrote: > > Hi everyone, > > > > The chosen fix[1] unfortunately introduced a new regression[2].

Re: Lazy operations refactor regression with abstract models #25858

mercredi 10 février 2016 16:29:52 UTC-5, charettes a écrit : > > I should have mentioned that this behavior is reproducible since at least > Django 1.6 and has not been introduced by Django 1.8. I wouldn't be > surprised > if it has always been working before the fix was introduced. &g

Unified temporal subtraction support

I recently worked on making substraction of temporal fields return a `DurationField` on all database backends[1]: class TemporalModel(models.Model): from_date = models.DateField() to_date = models.DateField() from_time = models.TimeField() to_time = models.TimeField()

Re: TransactionManagementError is raised when autocommit …

Hi Tore, Is there a reason you can't simply wrap your updates in a `transaction.atomic()` blocks? You should be able to avoid deadlocks and control exactly when data is written to disk with this construct. Simon Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit : > > Reply to

Usage of DjangoRuntimeWarning

During a review session I noticed the existence of `DjangoRuntimeWarning`[1] which was introduced in order to be subclassed to warn about about cache keys that are not compatible with Memcache[2]. As our test suite demonstrate subclassing `RuntimeWarning` can be quite useful when you want to

Re: re-thinking middleware

Hi Tim, I think we should favor displaying a message in accordance with the setting the user is using as it will make the transition less confusing. In the case of the documented check message I think using the form "MIDDLEWARE/MIDDLEWARE_CLASSES" would make it easier to read then mentioning

Re: Template-based widget rendering

Did we consider defining a template loader that knows where to load the widget templates from instead of requiring 'django.forms' in INSTALLED_APPS with 'APP_DIRS': True in TEMPLATES? Something along theese lines make more sense to me: TEMPLATES = { { 'BACKEND':

Re: ***SPAM*** Re: Middleware+Transactions:

As MIDDLEWARE supports decorator-like objects you could simply add `django.db.transaction.atomic' to it and you'd get each request wrapped in a transaction. Note that this will only start a transaction on the `default` database, just like the old TransactionMiddleware use to do. Simon Le

Re: Unicode normalization for username field

Hi David, I agree with your reasoning but I think you're missing an important detail about unicode username support: they have been mistakenly enabled on Python 3 since Django added support for it (1.5-1.6). If we were to disallow non-ASCII characters silently from Django 1.10 Python 3

Re: django-mssql present and future

Hi Michael, > To me the most important reason is, I want to start from scratch to help document what is involved with creating a database backend. I agree, such documentation is definitely lacking and even if it wont be commonly used it's invaluable for the rare developers needing it. Are you

Re: Support of model_object.delete(cascade=True)

Hi Sven, I agree with Tim about the fact such an option could be dangerous as you can't control the extent of the cascade. We removed the depth parameter of `QuerySet.select_related()` method for similar reasons and in this case you only ended up with a slow query not possibly purged data.

Re: Binding LiveServerTestCase bind to port 0

I've never personally used DJANGO_LIVE_TEST_SERVER_ADDRESS for another purpose than preventing port conflicts which binding to port 0 solves. It always looked strange to me to rely on an environment variable to achieve this. It feels like it was done this way to avoid introducing yet another

Re: Support for `Q` objects in `get_or_create` and `update_or_create`

Hi Flavio, Is there a reason we can't document chaining filter() with these methods when querying with Q() objects? Person.objects.filter( Q(first_name='George') | Q(first_name='Bruce') ).get_or_create(defaults={'last_name': 'Harrison'}) If `defaults` was stil only passable as a kwarg this

Re: slow migrations

Hello Venelin, Thanks for thanking the time to investigate the source of the slowdown you were experiencing on your project. I know you mentioned it would require a lot of effort to port your project to Django 1.10 but I'm pretty sure recent changes to RenameModel.state_forward would solve

Re: Some thoughts about improving migration squashing

> RemoveField('A', 'foo') also references A and foo, but does it reference B? if it does, then it' s hard to have optimizations that pass through this, because this field could be referencing any model (theoretically). I think we all agree on that. > But if we assert that RemoveField doesn't

Re: Some thoughts about improving migration squashing

xpressing its "RemoveField" indirect >> dependency to m' because another operation will do it for them. >> >> >> >> It's hard to generalize this across everything because there are, after >> all, arbitrary migrations. But considerin

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. I also think this is the most appropriate solution. Le lundi 13 février 2017 09:57:49 UTC-5, Tim Graham a écrit : > > Once in a while, there's a

Re: Some thoughts about improving migration squashing

Hi Raphael, I've been working on making the optimizer a bit smarter recently and came to the same conclusion as you concerning the "left" and "right" optimizations. This should be possible to solve by allowing `Operation.reduce()` to return the full list of operations it replaces by appending

Re: dumpdata --natural-primary --natural-foreign not serializing pointers to parents in multi-table inheritance

Hi João, It seems like this is an already reported bug[1] with an existing stale PR[2] you might want to work on. Cheers, Simon [1] https://code.djangoproject.com/ticket/24607 [2] https://github.com/django/django/pull/4473 Le samedi 10 septembre 2016 10:32:01 UTC-4, João Sampaio a écrit : > >

Re: Admin: Allow FilterSpecs to return Q-likes

> So I suppose my question is this - are there any operations that return a queryset that couldn't be captured in a Q object? Annotations are a good example of operations that cannot be expressed in a Q object. On the ticket I suggested relying on the "sticky filter" feature of the ORM to

Re: Allow validators to short-circuit in form field validation

Hi Alexey, I'm not sure I understand why the approach Aymeric suggested is not viable for your use case. It can be implemented in a few lines and doesn't require any modification to Django core. class ShortCircuitValidator(object): def __init__(self, *validators): self.validators

Re: Rethinking migrations

.2016, 00:58 użytkownik charettes <chare...@gmail.com > > napisał: > >> I have to agree with Marteen. >> >> From my experience what really slow down the migrate and makemigrations >> command is the rendering of model states into concrete model classes. This &g

Re: Rethinking migrations

I have to agree with Marteen. >From my experience what really slow down the migrate and makemigrations command is the rendering of model states into concrete model classes. This is something I concluded from my work on adding the plan object to pre_migrate and post_migrate signals. As soon as

Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

+1 Le jeudi 12 janvier 2017 08:11:09 UTC-5, Florian Apolloner a écrit : > > > > On Thursday, January 12, 2017 at 11:56:49 AM UTC+1, Marc Tamlyn wrote: >> >> DEFAULT_CONTENT_TYPE does sound like a setting which shouldn't exist. >> > > +1 > -- You received this message because you are subscribed

Re: Adding UNION/INTERSECT/EXCEPT to the ORM

+1 to QuerySet.difference() Le mercredi 11 janvier 2017 17:00:12 UTC-5, sebleier a écrit : > > We cannot use the name "QuerySet.except()" since except is a reserved word >> in Python. Do you prefer minus() (as suggested by Florian), except_() (as >> done by SQLAlchemy), or something else? >> >>

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

Hey Tim, I just wanted to mention that another approach for a transition plan could be to use {% load include from future %} like we did with the {% url %} tag. That doesn't answer the question of whether or not we should make the change but I think it offers a better upgrade path than a global

Re: Adding UNION/INTERSECT/EXCEPT to the ORM

Hey Florian! > How can I change the generated order_by clause to reference the columns "unqualified" (ie without table name), can I somehow just realias every column? Now that we have F() aliasing working in iterator() I would suggest to restrict all combined queries to have the same set on

Re: [Feature Request] Shorthand syntax for filtering aggregations

Hello Tom, Thanks for working on adding filter support to aggregate. I think adding support for the SQL:2003 features on all aggregates by emulating it on backends that don't support it using CASE makes a lot of sense[0]. As I've mentioned on your PR this is syntactic sugar I've been missing

Re: [Feature Request] Shorthand syntax for filtering aggregations

to be a CASE statement before > calling `super().as_sql()`. > > Thoughts? > > > On Mon, Apr 17, 2017 at 5:45 AM, charettes <chare...@gmail.com > > wrote: > >> Hello Tom, >> >> Thanks for working on adding filter support to aggregate. I think adding

Re: Problems around SchemaEditor._alter_field

Hey Florian, I think both options are viable. The main issue with a feature flag would be that it isn't tested by our CI. I guess we could make it True on SQLite and have it call remake_table to have some tests rely on it or mock it to True in tests and make sure everything goes well. In all

PostgreSQL aggregation and views through unmanaged models

Hello fellow developers, As some of you may know PostgreSQL 9.1 added support for GROUP'ing BY selected table primary keys[0] only. Five years ago it was reported[1] that Django could rely on this feature to speed up aggregation on models backed up by tables with either many fields or a few large

Re: Makemigrations hooks for third-party apps?

Hello Craig, There's unfortunately no way to hook into the migration auto-detector to specify additional operations to be added. What I suggest you do instead is dynamically inject operations in the plan that is about to be run by connecting a pre_migrate signal. When you detect CreateModel

Re: New Feature: Allow password reset token to expire in under a day

That's what I proposed on the ticket but I feel like it felt odd to me, the setting name does't suggest this is possible and it might be hard to achieve exact second precious because of float rounding? In my opinion introducing PASSWORD_RESET_TIMEOUT with timedelta support would be the best

Re: Implement a custom range-based filter for date_heirarchy

Hello Haki, I think the optimizations you are suggesting and the way you've implemented them make a lot of sense. I left a few comments on your PR[0] regarding the template tag in charge of rendering the date hierarchy header in the list view which could benefit from the same optimization but

Re: Adding an Index to a model with a custom Field.

Hello Jan, I'm a bit surprised the `contribute_to_class` approach isn't working but I remember there was previous discussions to support passing an `Index` instance to the `Field.db_index` option or to allow an `index_class` attribute to be defined on `Field` subclasses to determine what kind

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

Shai, `execute_wrapper` can be useful to prevent any queries from happening at all but I believe there's merit in wanting to prevent objects retrieved from a queryset from executing ghost queries during manipulations of the returned `Model` instances while allowing other unrelated queries to be

Re: PR 9583 - Ticket 28643

Hey Matthew, I could see adding support for F('field')[0:5] being useful and more intuitive than using Left/Right/Substr. You should be able to assert the field is sliceable (e.g. an instance of CharField/TextField) in the expression returned by F.__getitem__ (e.g. Left/Right/Substr)

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

to create it's forward descriptor[1]. That gives me hope that it should be feasible to add such a feature to core if deemed useful without invasive changes. Cheers, Simon [0] https://github.com/charettes/django-seal [1] https://github.com/django/django/blob/602481d0c9edb79692955e073fa481c322f1df47

Re: A Django Async Roadmap

criptors would error out. Cheers, Simon P.-S. While the project might look complex most of the code takes care of the delicate tasks of replacing fields descriptors once models are configured which could be significantly simplified if it was part of Django core. [0] https://github.com/charettes/d

Re: A Django Async Roadmap

19:34:11 UTC-4, Curtis Maloney a écrit : > > In general this sounds like a tremendously useful tool... I'm caused to > wonder, however... what, if any, are the performance impacts? > > -- > Curtis > > > > On 08/21/2018 08:10 AM, charettes wrote: > > Regarding

Re: Proposal: relationships based on arbitrary predicates

Hello Alex! Thanks for your work on this project, this is definitely something that I believe would be useful in Django's core based on the number of times I implemented a filtered queryset getter on Models. I'm not totally sold on the API but having an analog of what ForeignObject is to

  1   2   3   >