Re: created_at / modified_at on all database tables

I also think that this won't need to be in core since a Model Subclass works. We use this in our Application since we can't hard delete stuff so we overwritten the Model Field and the manager that all tables contain a date_deleted field which will be set when calling delete() objects.delete(). And

Re: Support for UNLOGGED tables in PostgreSQL

Wouldn't it be enough to just have link to the correct PostgreSQL site: http://www.postgresql.org/docs/current/static/non-durability.html And then some text with "if you want to run your tests on postgresql please see the docs around non durable postgres" 2015-07-13 18:46 GMT+02:00 Federico

Re: ANN: Django website redesign launched

Somehow I hate it. The website is the worst website I've seen since a long time. The contrast is really aweful. The issue Tracker got unusable due to the colors that aren't focused on readability. Overall it looks like a mess, just to have a new design. Doesn't look like a designer or a graphic

Re: Configurable safety options for high performance Django systems

> > Nope. a large OFFSET of N will read through N rows, regardless index > coverage. see http://www.postgresql.org/docs/9.1/static/queries-limit.html > That's simple not true. If you define a Order By with a well indexes query, the database will only do a bitmap scan. This wiki isn't well

Re: Configurable safety options for high performance Django systems

A sequence scan will only be made, if you query non indexed values. So if you add a simple ORDER BY you will make a index scan, which is very fast. The problem relies more on the database than on the ORM. As already said. If you need to deal with that much queries you need to log your SQL

Re: Configurable safety options for high performance Django systems

Sorry, but I don't think this is suitable. If somebody has 100M rows per Table then, he should prolly think about sharding/replication anyway. So the ORM would still suffer anyway. Currently my company has a few tables with a high count as well but since we never used the django-admin and managed

Re: Requiring GitHub login for actions on Trac

I'm a little bit concerned about that. First I'm using a different user on Trac than on Github, so everything I wrote so far will getting lost (not that bad problem for me), but I think there are many users who are in the same situation. The next thing is vendor lock-in. What will happen if

Re: Updating the organization of the Django Project

using trac is not. >> trac is a really blocker for a lot of things on my side. i think the ux is >> somewhat bad, but thats just an own perspective. >> >> >> >> >> 2014-08-01 21:49 GMT+02:00 Carl Meyer <ca...@oddbird.net>: >> >>> Hi Chr

Re: Updating the organization of the Django Project

things on my side. i think the ux is somewhat bad, but thats just an own perspective. 2014-08-01 21:49 GMT+02:00 Carl Meyer <c...@oddbird.net>: > Hi Christian, > > On 08/01/2014 01:37 PM, Schmitt, Christian wrote: > [snip] > > i mean maybe we should really look at a

Re: Loading fixtures once for each TestCase to improve running time

Just a quick question regarding to these posts / tickets. In the last few weeks we fixed: https://code.djangoproject.com/ticket/22487 So I think that we now don't need to rely on fixtures and should just tell the people to use that behavior in the first place. I mean I'm not a Django core

Re: [GSoC] Switching to Jinja2 proposal

I'm not a django-developer, but I'm creating a lot of applications with Django and I would never want to switch to Jinja2. Why? The first thing is that Django Templates are simple to understand, they are not formed as a new DSL or a Programmable way of a Template language. Their Syntax is clear

Re: 1.7 Release Schedule

I also hoped that the release date will be way before the 15th of may. Also just a question.. I currently looking forward to maybe contribute something back to django. But I always struggle with trac it looks so extremly messy. I mean i try to query some unresolved, accepted queries: