Re: Django 1.6 release timeline

On Tuesday 30 April 2013, Jacob Kaplan-Moss wrote: > Hi folks - > > Unless there are strong objections, here's what I'm thinking for the > Django 1.6 release timeline: > > Alpha: May 16 > Beta: June 20 > RC: Aug 1 > Final: as early as Aug 8, or later if more RCs are needed. > I see one issue wit

Re: runserver fails on non-fatal model validation errors

Hi all, I've been going through what I've missed on the list, and found this 2-month- old message that seems to have gone unanswered. I'm sorry for being so late to the party, but... On Saturday 23 March 2013, Brendan Jurd wrote: > > I reported an issue with runserver on the django trac [1], an

Triaging: Close as needsinfo

Hi Django devs, I would like to raise a little concern I ran into lately. When going over some Oracle-related tickets, I came across ticket #20201[0] . The ticket description was missing important details, so I commented about them. A few days later, Aymeric came around, and closed the ticket a

Re: first() and last(), earliest() and latest()

Hi Selwin, On Saturday 11 May 2013, Selwin Ong wrote: > Hi everyone, > > I submitted a pull request implementing "first()" and "last()" here: > https://github.com/django/django/pull/1054 > > Comments welcome! > You implemented the "order_by" parameter as taking only one field name; this is in

Re: reconsider re-opening ticket 901

On Saturday 11 May 2013, Anssi Kääriäinen wrote: > > - While it might seem trivial to implement reload()/refresh() when > needed, Indeed, it might; which is why I would assume many people have already done it. For these people, a new reload()/refresh() in core may go unnoticed or redundantly

Re: reconsider re-opening ticket 901

[resend, reference included; sorrt for the noise] On Saturday 11 May 2013, Anssi Kääriäinen wrote: > > - While it might seem trivial to implement reload()/refresh() when > needed, Indeed, it might; which is why I would assume many people have already done it. For these people, a new reload()/

Re: Triaging: Close as needsinfo

On Sunday 12 May 2013, Łukasz Rekucki wrote: > Hi, > > On 11 May 2013 22:58, Shai Berger wrote: > > In > > other communities, I have usually seen "needsinfo" as a ticket state, > > rather > > than a reason for closing; such tickets are then closed late

Re: reconsider re-opening ticket 901

Hi, There's one minor issue that I'm not entirely clear of with this proposal: On Sunday 12 May 2013, Anssi Kääriäinen wrote: > > Concrete API proposal: Model.refresh() reloads all non-deferred local > field values (that is, all fields in the current model which have a > database column). In add

Re: reconsider re-opening ticket 901

On Sunday 12 May 2013, Aymeric Augustin wrote: > On 12 mai 2013, at 10:24, Shai Berger wrote: > > Relatedly, we now cache back-references of 1-to-1 relations on the > > instance > > Django has cached them for a long time. It's just a bit more efficient and > d

Re: Perception of attitude in tickets

Hi, On Monday 13 May 2013, Tom Evans wrote: > > Perhaps this wasn't clear, that was a member of your community trying > to make it happen. There have been several attempts over the past 5 > years by people trying to make it happen. Each time someone has tried > to make it happen, after the initia

Re: Perception of attitude in tickets

Hi Tom, On Monday 13 May 2013, Tom Evans wrote: > > You're not the only person who has time constraints, each of has a > choice of what we work on in our spare time. When I read these sorts > of tickets, perfectly valid feature requests knocked down for > precisely no reason, why should I waste m

Re: reconsider re-opening ticket 901

On Tuesday 14 May 2013, Alex Ogier wrote: > > It's a totally new behavior that has > plenty of corner cases such as foreign keys, and especially OneToOneFields. > Another one is initializers: get() or any other method of fetching an object from the database will call __init__() with the fields

Re: Perception of attitude in tickets

On Wednesday 15 May 2013, Luke Plant wrote: > > So I've gone ahead and created a wiki page, which can be longer and more > friendly, and require a shorter response on the actual ticket, something > like this: > > Closing as WONTFIX because ... > > If you want to persuade us otherwise, please

Remote participation in sprints

Hi all, This saturday and sunday there are supposed to be sprints in DjangoCon EU in Warsaw. To my regret, I could not be present at the conference. However, I may be able to set aside the two days and participate in the sprint remotely. Will there be an effective way to do this while communica

Re: Remote participation in sprints

On Wednesday 15 May 2013, ptone wrote: > On Wednesday, May 15, 2013 10:31:36 AM UTC-7, Daniele Procida wrote: > > On Wed, May 15, 2013, Shai Berger > > > > > > >Will there be an effective way to do this while communicating with the > > >developers present

Re: Reminder: pending Oracle fixes and issues

Hi, Resurrecting a 4-month-old thread: On Sunday 20 January 2013 10:05:16 Anssi Kääriäinen wrote: > On 20 tammi, 02:52, Shai Berger wrote: > > Which still leaves two issues -- PR #393 (faster processign of numbers; I > > think I forgot to mention earlier -- it is just some fixes

Re: first() and last(), earliest() and latest()

Two notes: 1) I think it is better to leave the *args, **kw on the manager methods; since they are just forwarding to the qset anyways, there's no harm in that, and it makes them more "future proof" (i.e. you wouldn't need to change them next time you change the interface of the qset methods).

Re: django and paramstyle: what's the actual story?

On Thursday 16 May 2013, VernonCole wrote: > I noticed in a recent post that there is an outstanding patch for Oracle > for support of 'named' paramstyle. > As the author of that patch, I should probably clarify that it is a "format" style -- %(name)s -- not a "named" -- :name -- style. AFAIK,

Re: Django's problem with db-level defaults on Oracle

On Saturday 01 November 2014 11:55:26 Kääriäinen Anssi wrote: > Quick question: could django set the default to to_date('2014-31-01', > '-mm-dd')? Yes, apparently we could, and it would solve the problem I described earlier, thanks. If we decide to start using defaults in the database (which

Re: Setting database default values in migrations (postgres)

On Friday 31 October 2014 19:16:15 Jon Dufresne wrote: > On Fri, Oct 31, 2014 at 9:46 AM, Andrew Godwin wrote: > > So, bear in mind that you can easily set these defaults yourself in a > > migration with RunSQL if you need them for legacy purposes; that way > > they'll get applied > > Absolutely.

Re: Unicode SlugField design decision (#16501)

On Wednesday 05 November 2014 17:29:20 Michael Manfre wrote: > We can change the internal type of SlugField for option 1 based upon > whether or not the field should be unicode. Whether or not an existing > backend stores SlugField in an ascii char datatype shouldn't dictate > whether we go with Sl

Re: Please add exists subquery to queryset api

Hello George, On Sunday 09 November 2014 05:33:36 George Ma wrote: > I've encountered quite a few cases where I need to write complicated > queries where a exists subquery makes more sense and has better > performance. So far, there's no exists subquey support in queryset api. > Please add it. I

Backend-specific lookups

Hi, I'v been working on an old Oracle bug[1], and realized that a nice way to solve it would be by overriding some builtin lookups with custom lookups for Oracle. However, I had some doubts about where to place the code: On the one hand, I could just add an "as_oracle()" to the builtin lookup

Re: Backend-specific lookups

On Sunday 16 November 2014 00:46:43 Josh Smeaton wrote: > Clever. I don't mind this approach at all. Will the overriding of > get_db_prep_lookup interfere with other implementations though? > Yes, it probably would. It is there because the default one for the lookup adds % signs around the value

Re: Backend-specific lookups

I just wanted to drop a line here saying "it will take me another couple of days to deal with this". On one hand, I want to wait with this for Marc's work to land. On the other, there are more urgent issues even in Oracle-land (the broken Py3 tests). And yes, I'm with Anssi on removing get_db_p

Re: Configurable safety options for high performance Django systems

Hi Rick, On Sunday 23 November 2014 14:11:13 Rick van Hattem wrote: > > So please, can anyone give a good argument as to why any sane person would > have a problem with a huge default limit which will kill the performance of > your site anyhow but isn't enough to kill the entire system? > ...bec

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Hi, Just noted this thread, and I have two points: 1) Using the migration name in the index isn't really "predictable", and isn't even completely stable (the name changes when migrations are squashed), unless I'm missing something. 2) The current practice of identifying indexes by the columns

Re: Experimental APIs DEP

I like the general idea of experimental API, although Carl and Aymeric's notes are important: If we do this, we need to very picky in its use, or else it just becomes an easy route to avoid committment. In particular, there should be a hard-and-fast rule that nothing should be made an "experimen

annotate() and generic relations

Hi everyone, First, there was ticket #10461[1] -- a complaint that annotate doesn't work well with generic relations. Then, it was documented[2] as not working. But then, people continued looking at the ticket, and in the end, it was declared as fixed and a test was added[3]. But deeper checkin

Re: Bypassing 1.7+ migrations

FWIW, the approach I would go for is to try to monkeypatch managed=False into the base model Meta. Shai. On Tuesday 16 December 2014 14:49:25 Andrew Godwin wrote: > Hi Marcin, > > You can't bypass migrations as much as you can't bypass syncdb; that is, > the commands are separate and you can ch

Re: annotate() and generic relations

Hi Anssi, Thanks for that quick fix. On Wednesday 17 December 2014 10:16:27 Anssi Kääriäinen wrote: > > It turns out this is easy to fix. There is a patch for this at > https://github.com/django/django/pull/3743. > (All: In case you're interested but lazy -- this was committed) > The generic r

Re: Bypassing 1.7+ migrations

Hi Markus, On Thursday 18 December 2014 08:54:30 Markus Holtermann wrote: > > manage=False won't gain you anything, since those models will still show > up in migrations, because they need to be able to be referenced by > managed models. The migration database operations are noops though. > As

Re: intended security model for templates

On Wednesday 24 December 2014 20:35:09 Tim Graham wrote: > I was hoping to get clarification on what security model we intend to > support for template authors. In ticket #12772 > it's proposed to allow > loading template tags using a dotted Python path

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

On Wednesday 04 February 2015 11:00:50 Tom Christie wrote: > > it will be backwards incompatible for every Django installation out > > there, but also because throwing away data that the user actually entered > should be an opt-in, not opt-out behavior. > > If adequately called out I think there'

Re: discontinue shipping tests with contrib apps?

On Monday 09 February 2015 17:38:27 Markus Holtermann wrote: > I'm +1 on moving the contrib tests to tests/_tests/ . > I'm +1 on preventing tests from being packaged with the contrib apps; I'm also +1 on moving them out of the app folders in the source -- +0 for the move's inherent value, but +1

Re: Adding missing aggregate functions to contrib.postgres ?

On Monday 09 February 2015 02:01:03 Russell Keith-Magee wrote: > > The only other thing I'd flag is that if any of these aggregates are recent > additions (e.g., added in Postgres 9), the failure mode for earlier > versions should be relatively clean. > Nitpick: Django 1.8 -- the first to have dj

Relations to non-trivial fields

Hi all, This comes from trying to fix #24343[1] -- a problem where a UUIDField is used as a PK (legitimate and common practice), and we wish to test a FK to that model. The problem is that, on database backends which do not support native UUIDFields (that is, all but postgres), the underlying f

Re: Psycopg2 version support

Hi all, On Saturday 14 February 2015 22:53:13 Marc Tamlyn wrote: > > Django 1.8 will necessarily be the first version with a true minimum > requirement on psycopg2 version. Historically we have never documented a > required version. > FWIW, we have long had minimum requirements for other backen

Re: A general way to batch SQL queries in Django

On Saturday 28 February 2015 23:05:56 Ram Rachum wrote: > > Here is what I'm currently thinking about: Can we make Django do multiple > separate queries (SQL queries are separated by a semicolon right? Sorry for > being a noob) and send them one after another before blocking on reading > any of t

Re: Password validation in Django revisited

Hi Erik and all, The approach, indeed, seems fine, which is far from trivial. Some details, of course, still need to be worked out. I like Aymeric's suggestion re help_text -- I would take that one step further and allow every validator to give its own list of requirements. I have one "devil's

Re: GSOC 2015: Improving the less popular database backends

One point which may be relatively easy and valuable is to get Django to support backend-provided tests, and do the final clean-up of backend-specific tests from the general test suite. That is, put all the postgres-specific tests somewhere in django.db.backends.postgresql_psycopg2 etc, and have

Re: inspectdb database defaults

On Tuesday 10 March 2015 19:39:19 Michael Manfre wrote: > I agree with Tim. > > I would support refactoring inspectdb so that it would be easier for anyone > to subclass the command and add additional logic to the introspection > process. +1. Shai.

Re: Don't understand regex-urls and DetailView...

On Wednesday 11 March 2015 22:56:15 inoyon artlover KLANGRAUSCH wrote: > > url(r'^(P?\w+)$', views.ProductView.as_view()), > > Where is the mistake here That should be url(r'^(?P... The question mark before the P In the future, please direct questions about using Django to the dj

Re: GSoC 2015: Template engine optimisation

On Wednesday 11 March 2015 23:40:39 Oleksii Oleksenko wrote: >- Profiling > - run profiler (cProfile?) on all of these tests. As I see, basic > algorithm (pseudo code) will look like this: > > for context, template in zip(contexts, templates): > t = Template(template) > c =

Re: GSOC 2015: Improving the less popular database backends

On Sunday 15 March 2015 03:45:16 Yichun Duan wrote: > Thank you. When you say "backend-provided tests", do you mean MySQL > scripts, Oracle scripts or something else like these? Or just some tests > based on django standard, which have marks to tell test runner the backend > they suite? > I mean

Re: GSOC 2015: Improving the less popular database backends

14:03:44 Yichun Duan wrote: > And another question, how long will this task take in your opinion? I can > hardly estimate it now. > > 在 2015年3月15日星期日 UTC+8下午7:07:11，Shai Berger写道： > > > On Sunday 15 March 2015 03:45:16 Yichun Duan wrote: > > > Thank you. When y

Re: Help needed with Oracle GIS backend

Hi Jani. On Wednesday 25 March 2015 09:58:00 Jani Tiainen wrote: > > We're still running Oracle and GIS. Though we do have built custom > backend based on Django GIS backend - mainly to have support for > Oracle XE, 3D functionality and in general to make it faster. > > It's currently closed sou

Re: ModelManager behaviour for Proxy Models

Hi Mahmud, On Tuesday 31 March 2015 16:17:52 mahmudul islam wrote: > I am not sure about the current development branch but last time I checked, > performing query on proxy models by default considers all the objects of > the parent/base class. If anyone is to consider only the objects of that > c

Re: django-admin.py shebang

On Wednesday 01 April 2015 18:34:35 James Bennett wrote: > On Wed, Apr 1, 2015 at 10:28 AM, Stan wrote: > > A classical pip install Django command without --mirrors or --use-mirrors > > modifier. > > > > I did some --upgrade, but the first installation is not 10 years old (2 > > maybe). > > > >

Re: Using AbstractBaseUser without django.contrib.auth

On Thursday 02 April 2015 05:50:04 Curtis Maloney wrote: > Does your model inherit from PermissionsMixin? > > If you're using Admin, or any of Django's permissions machinery, you will > need django.contrib.auth in there to use the Group and Permission models. > The problem is not with permission

Re: 1.9 release planning

On Saturday 04 April 2015 21:16:54 Michael Manfre wrote: > On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner wrote: > > I think rare LTS releases and frequent (6month) incremental upgrades are > > a good compromise. > > Third-party packages should support LTS releases and at least the latest > > Djan

Re: 1.9 release planning

On Monday 06 April 2015 23:34:09 Chris Foresman wrote: > I'm really curious to know if the version to follow 1.9 is planned to be > 2.0 or 1.10. I feel as though 1.x releases have had a lot of major feature > changes. Maybe it's time to start thinking about features in terms of > major, minor, and

Re: Request for help: building a docker/vagrant platform for running Django's test suite

On Saturday 18 April 2015 02:27:17 Tim Graham wrote: > I would like a knowledgeable person who has time and interest to take the > lead on this and I could work with you based on my experience with Jenkins. > Feedback welcome! > I am not an expert on any of the tech involved, I just wanted to poin

Re: Idea/request for help: Django Developers Community Survey

Hi, On Saturday 25 April 2015 15:29:30 Tim Graham wrote: > Aymeric and I put together a draft: > > https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxW > w/viewform > > All questions are optional so you can just click through it to view the > questions. We'll probably clea

Re: one patch to fix a Django 1.8 issue for merging legacy database

Hi Ben, Thanks for the change you suggested. On Tuesday 28 April 2015 09:48:26 Ben L wrote: >[paraphrase] An automatic primary key shouldn't be added to unmanaged models, >[paraphrase] the current behavior where it is added is a bug Please have a look at the documentation[1] -- it states clearl

Re: Allow deferral of ModelSignal callback invocation until after transaction commit

Hi, On Saturday 02 May 2015 07:20:00 Christopher Adams wrote: > Hey guys, > > Thanks for the great feedback and replies. > > Generally agree with everyone that post-commit hooks shouldn't be strictly > coupled to the signals framework philosophically speaking. > > I disagree with Carl's premise

Re: Capturing faked migrations in django_migrations table

I think we had this discussion, more-or-less, around South migrations (I looked a little, but couldn't find it). The context there was, as Tim hinted, "forensics" -- trying to figure out how a system came into its (broken) state. For that (as well as the OP's case, AFAICT) it makes little sense

Re: Is improving Django's communication with Oracle databases on the roadmap?

he research wing of Moffitt Cancer > >> Center, and our shop uses django for +10 in-house applications, running > >> almost exclusively against oracle applications. Django has enabled > >> building some great applications, but the performance is kind of > >> terrible w

Re: Capturing faked migrations in django_migrations table

Hi Steve, On Wednesday 20 May 2015 01:50:15 steve byerly wrote: > > I'm also unclear what the argument against storing in the migrations table > is vs logging them - honest question. Since I have 4 web servers, the > information would be logged to any one of them - depending on which > executed t

Re: Call stacks for Model classes

Hi, Please ask questions about developing with Django on the django-users group. This group is for discussions about the development of Django itself. (as a general rule: decorating single methods should work fine; trying to use decorators on model classes will probably be painful. These classe

Re: Making management forms for formsets optional

Semi-devil's-advocate suggestion: Replace the management form with a management field, a hidden field with name = "__manage__%s" % (formsetname) and value="x" Then instead of taking the number of forms from a field on a management form, we can just take the accumulated leng

Re: Using `SECRET_KEY` in password hashers

On Tuesday 09 June 2015 08:23:03 Ram Rachum wrote: > On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney > wrote: > > On 9 June 2015 at 15:16, Ram Rachum wrote: > >> > >> What do you think about using the project's `SECRET_KEY` as an > >> additional salt in Django's password hashers? > > > I think i

Re: Tips on adding a Couchbase backend

On Sunday 14 June 2015 00:13:33 Mark Nunberg wrote: > Hi folks! > > I apologize in advance if this is the wrong venue for this discussion > > I'm trying to determine the best means by which I might be able to add > Couchbase (http://www.couchbase.com) support to Django. I've come across > somethi

Re: Django Admin - list_display default value

(I received the message I'm replying to here with an empty subject, and detached from the thread. Google Groups being funny?) On Monday 15 June 2015 22:52:09 Rick van Hattem wrote: > On 15 June 2015 at 21:34, Florian Apolloner wrote: > > On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hat

Re: Request: initialize fields with built-in class defaults

Hi Bobby, I'm not sure what you mean by "fields don't allow built-in defaults". While it's true that Django's DateField (for example) doesn't have a built-in default, here's[1] a custom field with a built-in default: class MyDateField(models.DateField): EPOCH = date(197

DecimalField with no max_digits and decimal_places

Hi, Django's DecimalField requires both max_digits and decimal_places. Database backends allow them to be dropped, to specify an "unlimited precision" field. Adding support for this in Django is probably not very helpful for new apps, but can help significantly in using Django against legacy da

Fwd: cx_Oracle 5.2

FYI. The news as far as Django users are concerned are mostly improved support for Oracle 12c (not yet used in Django core, but available for users nonetheless) and some minor bugfixes. Have fun, Shai. -- Forwarded Message -- Subject: cx_Oracle 5.2 Date: Sunday 21 Ju

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

On Tuesday 23 June 2015 15:50:14 Tim Graham wrote: > I don't think there's an "architecture rule" that would prevent that > design. It looks like DISALLOWED_USER_AGENTS has been around since 2005, > but handler403 wasn't added until 1.4. Since the docs for the setting say > "Use this for bad robots

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

to humans using browsers. On 24 ביוני 2015 11:08:32 GMT+03:00, Aymeric Augustin wrote: >2015-06-24 1:56 GMT+02:00 Shai Berger : > >> Could any of the supporters elaborate on the use-case? >> > >Just to clear a possible confusion -- this feature already exists, it >was

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

On Wednesday 24 June 2015 15:15:35 François Schiettecatte wrote: > > Sounds right, but you can do that already with handler403. The change > proposed changes the handling of the user agent to raising > PermissionDenied exception rather than returning a > HttpResponseForbidden(). > That is exactl

Re: Django 1.9 - JSONField

On Thursday 09 July 2015 00:18:09 Christopher Allan Webber wrote: > [...] It would > be nice to get this included into Django itself, and have it noted as a > Postgres-only feature. Then if other databases can eventually catch up, > include them alongside it. > I have to repeat Marc's implied qu

Re: Support for UNLOGGED tables in PostgreSQL

This is a shot in the dark: Could it be that rolling back transactions involving unlogged tables is harder? The idea does make sense, and running the test suite does an extremely untypical amount of rollbacks. On Wednesday 15 July 2015 16:19:47 Federico Capoano wrote: > That's quite baffling. >

Re: Why Django is making migrations for external apps?

On Thursday 16 July 2015 02:10:12 Andrew Godwin wrote: > > Also, yes, Django doesn't see unpacked .egg files as any different than > anything else (they're just directories after all) - we have no way of > telling which apps are yours and which are external, really. In my experience, most project

Re: Why Django is making migrations for external apps?

On Friday 17 July 2015 19:48:30 Carl Meyer wrote: > On 07/17/2015 10:38 AM, Marcin Nowak wrote: > > Sounds enough good. One important thing for me is that I have many of > > external apps and few in project managed by me. Reconfiguring most of > > apps just to tell Django "leave them alone" sounds

Re: Why Django is making migrations for external apps?

On Monday 20 July 2015 18:47:07 Carl Meyer wrote: > > > >> Personally I don't really see much use case for this feature > >> except as a workaround for reusable apps that generate spurious new > >> migrations based on settings changes > > > > I've also seen it with apps that use "EmailField" with

Re: Speedy Mail 2.0 - a new webmail platform in Python and Django

Hi Uri, On Tuesday 21 July 2015 21:05:03 Uri Even-Chen wrote: > To Django developers, > This list is for discussions about the development *of* Django. For issues of development *with* Django, please write to django-users. Thanks, Shai.

Re: Dynamic inlines for Django ModelAdmin

On Monday 27 July 2015 10:57:41 Florian Apolloner wrote: > Doesn't get_inline_instances > (https://github.com/django/django/blob/master/django/contrib/admin/options. > py#L520) do exactly that? > The request, as far as i understand, is to have the list of inline classes be determined dynamically

Re: Support for UNLOGGED tables in PostgreSQL

On Monday 20 July 2015 12:42:47 Federico Capoano wrote: > > Just a final note: I think this solution is not the optimal one I agree. The optimal solution would be for us to be able to define a test database with unlogged tables and all the data-integrity-sync options off, while the "production"

Re: future of QuerySet.extra()?

On Monday 03 August 2015 10:27:14 Anssi Kääriäinen wrote: > You can annotate raw SQL with expressions. I think the only case that can't > be done with expressions is addition of extra tables to the query. Also grouping over non-relations, if I am not mistaken. Shai.

Re: future of QuerySet.extra()?

Hi, On Tuesday 04 August 2015 03:28:03 Josh Smeaton wrote: > On Tuesday, 4 August 2015 07:10:05 UTC+10, Shai Berger wrote: > > On Monday 03 August 2015 10:27:14 Anssi Kääriäinen wrote: > > > You can annotate raw SQL with expressions. I think the only case that > > > can

Re: How to disable system check framework?

Hi all, On Tuesday 11 August 2015 19:05:26 Carl Meyer wrote: > On 08/11/2015 10:44 AM, Marcin Nowak wrote: > > I need to list ALL errors and warnings, which is: > > * unhandy and it would require maintain a big list (especially after > > upgrading Django to newer version) > > That's a good reas

Re: removing FlatPage.enable_comments field?

On 13 באוגוסט 2015 19:03:09 CEST, James Bennett wrote: >> >The field on FlatPage has been there since the beginning. The >moderation >stuff in the comments app was added later (I originally wrote it as a >third-party app, and it got integrated into contrib.comments >afterward). > So, what was t

Re: Django Admin New Look

On Tuesday 18 August 2015 14:29:15 Marc Tamlyn wrote: > I don't know about schedule, but caniuse reports IE8 browser usage at 1.5%, > more than IE9 or IE10. > > There's an argument we shouldn't be "enabling" people still using XP who > are stuck on IE8, and this is a decreasing problem, but I don'

Re: draft blog post for Oracle help

Hi all, On Wednesday 19 August 2015 15:06:17 Marc Tamlyn wrote: > Hi Jani, > > Thanks so much for sticking your hand up to help maintain Oracle! It is an > important part of our ecosystem. > I would like to add my voice in thanking Jani, and also Josh, for standing up for Oracle. Marc is right,

Re: Improving MSSQL and Azure SQL support on Django

On Saturday 22 August 2015 13:28:31 Aymeric Augustin wrote: > > There isn’t such a clear story for running Django on Linux. This led me to > write https://github.com/aaugustin/django-pymssql. Alternatives include > https://github.com/denisenkom/django-sqlserver and > https://github.com/lionheart/d

Re: templates block prepend and append

Hi and all, On Monday 24 August 2015 23:37:57 Collin Anderson wrote: > On Mon, Aug 24, 2015 at 2:25 AM, Amin Jun > > wrote: > > I liked his suggestion, I don't know if I'm using template tags > > correctly, but I'm writing a template tag {% load_comment > > comment_manager %} , "load_comment" re

Re: Ability to migrate other applications

On Tuesday 25 August 2015 05:13:14 Andrew Godwin wrote: > The main problem I forsee here is just making sure that the MigrationLoader > knows to take these located-in-the-wrong-place migrations and insert them > into the migration tree right - in particular, you have issues with the > dependencies,

Re: Ticket #25328 - LiveServerTestCase with HTTPS - opinions?

Hi, On Monday 31 August 2015 21:24:53 Tim Graham wrote: > however, there was previous discussion about adding SSL support to > runserver met with mixed reaction [1] and it seems a little funny to me > that we'd including a test SSL server and not a runserver solution. > > [1] > https://groups.goo

Re: Ability to migrate other applications

Hi, On Thursday 03 September 2015 12:44:08 Emmanuelle Delescolle wrote: [Markus Holtermann wrote:] > > But as Andrew already said, you *will have* problems when you have your > > own migrations and a third party app adds a new one. Suddenly there are > > two leafs which is an invalid state. You w

Re: Making the test suite run faster

Hi, On Sunday 06 September 2015 13:06:18 Aymeric Augustin wrote: > > This will require ./runtests.py --no-parallel or ./runtests.py > --parallel-num=1 to run tests under Oracle. I think it’s a good tradeoff > because the defaults should be optimized for occasional contributors. > Can we somehow

Re: Password validation in Django revisited

On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote: > I agree with Aymeric and Markus that createsuperuser should not validate > strength of passwords when DEBUG is on. Having to use a secure password for > development/test accounts is an unnecessary level of interference for > users. > > I ag

Re: Ability to migrate other applications

Ok, two things: 1) Markus' idea of having more than one folder for migration modules seems reasonable enough. I disagree with his comment about the placement of merge migrations -- > Django needs to know where to > place the merge-migration. I'd go with the first item in the list I'd require

Re: Ability to migrate other applications

On 9 בספטמבר 2015 13:29:58 GMT+03:00, Marten Kenbeek wrote: > >> >> The order of migrations isn't something which is local to this >feature, it >> is something which isn't fixed (probably by design, correct me if I'm > >> wrong) and if it is not "the right way" to do it, maybe it should be >pa

Re: Ability to migrate other applications

On Wednesday 09 September 2015 16:35:16 Markus Holtermann wrote: > On Wednesday, September 9, 2015 at 9:21:43 PM UTC+10, Shai Berger wrote: > > On 9 בספטמבר 2015 13:29:58 GMT+03:00, Marten Kenbeek > > > > >The order of migrations within a single app is fixed. > > &g

Re: Ability to migrate other applications

Hi, On Thursday 10 September 2015 17:00:07 Emmanuelle Delescolle wrote: > As this thread is most likely leading to a dead-end, let me try to close it > by summarizing it: Not trying to re-open the thread, just that... > > Shai: This seemed a little far from what I said (or, at least, intended)

Re: created_at / modified_at on all database tables

Hi Aron, I think this feature does not belong in Django; hiding concrete parent fields sounds like a bad idea which is likely to open a whole can of worms and violated assumptions. Since the motivation for the unusual parent-and-child-fields comes from non- Django uses of the database, I suspec

Re: Capturing faked migrations in django_migrations table

Hi, On Wednesday 16 September 2015 03:13:35 Markus Holtermann wrote: > > I see the following solutions to bring this PR forward: > >1. Configure `django.db.migrations` logger to not send messages to >console by default and keep log levels to INFO (for "Applied/Unapplied >migration XY

Re: Feature Proposal: per-settings fake migration override

Hi, On Saturday 19 September 2015 14:02:38 Markus Holtermann wrote: > On September 19, 2015 6:38:59 AM GMT+10:00, > Flavio Curella wrote: > > > ># settings/production.py > >MIGRATION_FAKE = ( > > > >('transactions', '0001_initial), > > > >) > > This sounds like a very risky and scary propos

Re: Make DATABASES[x]['TEST']['USER'], etc available for non-Oracle DBs

On Monday 21 September 2015 00:46:51 m...@satchamo.com wrote: > Currently, the TEST database settings like USER and PASSWORD are only used > by the Oracle backend. > > See: > https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-TEST_USER > > I just hit a case where it would be nice to

Re: Why leave explicit null=True when blank is True in IntegerField, DateField etc?

Hi, (edited a little) On Tuesday 22 September 2015 03:07:37 Tim Graham wrote: > On Monday, September 21, 2015 at 6:52:08 PM UTC-4, Paulo Maciel wrote: > > Why confused? It's optional, if the developer wanna put null=True, he > > could. > > I don't think need to be putting null = True, this is red

<    1   2   3   4   5   6   7   >