Re: Fellow Report - October 17, 2015

2015-10-20 5:04 GMT+02:00 Michael Manfre : > My long term plan is to switch out ADO for replaceable ODBC and FreeTDS. > This may follow the current pattern Aymeric started when he created > django-pymssql, or have them both in django-mssql. For the record, django-sqlserver

Re: should manage.py test run system checks?

2015-10-20 2:48 GMT+02:00 Tim Graham : > me: I'm of the opinion that running the system checks as part of the manage.py > test command should be opt-in (for example, by writing a test that > asserts the call_command('check') output is empty. For example, when > debugging a

Re: Should contrib.auth include support for 2fa out of the box?

On 26 oct. 2015, at 18:22, Tim Graham wrote: > What do you think? I would very much like Django to have 2FA out of the box. Let’s bring django.contrib.auth kicking and screaming into the 2010’s ;-) I even considered crowdfunding it but that didn’t go much beyond idle

Re: Django TestCase isolation: setUp vs setUpClass

Hello Samantha, As of Django 1.8 there is a built-in solution to this problem: https://docs.djangoproject.com/en/1.8/topics/testing/tools/#django.test.TestCase.setUpTestData Best regards, --

Provide a way to pass kwargs when initializing the storage class

Hello, Currently the DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings contain a dotted Python path to the storage class. The class is instantiated without any arguments. ** Problem ** This leads to three annoyances. 1) Third-party libraries like django-storages(-redux) need to provide

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

match these options instead of the > proposed two-tuples? > > > -- > Raphaël > > > On Sat, 7 Nov 2015 12:15:49 +0100 > Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > >> Hello, >> >> Currently the DEFAULT_FILE_STORAGE an

Re: startproject values for STATICFILES_DIRS and TEMPLATES

Hello René, The current built-in projet template is designed to provide the minimal set of settings required for a functional admin and a good level of security. (A few months ago I would have just said "a functional admin", but a new setting was added since then.) As far as I can tell, the main

Technical board report - 1.8 release cycle

Hello, It recently occurred to the team that, in the interest of transparency and accountability, the technical board should publish a report on its activity at the end of each term. As a reminder, the technical board is a group of five people elected among the Django team who holds two

Re: Technical board report - 1.8 release cycle

Sorry, I missed one discussion: 6bis. December 29th, 2014: accepting DEP 182 (Multiple Template Engines). Decision: yes. -- Aymeric. > On 10 nov. 2015, at 20:41, Aymeric Augustin > <aymeric.augus...@polytechnique.org> wrote: > > Hello, > > It recen

Re: Form field labels change proposal

I’ve always been annoyed by having to define lower case model field labels and capitalized form field labels. Inconsistencies always creep in. I would like to see this suggestion implemented, if we can provide a decent upgrade story for Django users. -- Aymeric. > On 11 nov. 2015, at

Re: removing redirect URLs for some really old Django releases

I hope anyone who still cares about these versions has their own copy… -- Aymeric. > On 17 nov. 2015, at 17:46, Tim Graham wrote: > > I wonder if anyone objects to removing some non-trivial logic to support old > download redirect URLs: > >

Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

On 17 nov. 2015, at 18:00, Tim Graham wrote: > Do you think it's correct to make the change in Django itself? > https://github.com/django/django/pull/5676 > -- I didn't track down the > reason why this changed in Python.

Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

Considering the information provided by Donald, it’s pretty clear to me that we should switch to rc as proposed by Tim. -- Aymeric. > On 18 nov. 2015, at 01:26, Tim Graham wrote: > > Thanks Donald, updating setuptools was the factor I missed, not Python 2 vs. > 3. >

Re: manage.py test and uninstalled apps

Hello Claude, Generally speaking, you cannot safely use a model that isn't defined in an application that is in INSTALLED_APPS. Django raises a warning when you import such a model. This restriction prevents situations where relations between models aren't set up correctly. There’s a string

Re: manage.py test and uninstalled apps

2015-11-19 8:27 GMT+01:00 Claude Paroz : > To be clear, I don't contest in any way that design choice. I understand > and approve it. > I'm just pointing to this unwanted side-effect, wondering if anyone has > ideas how to circumvent it, as I think it's a legitimate use case.

Re: "Project" vs "App"

Hello Thomas, Thanks for bringing this up. There’s definitely some room for improving the documentation — I know because I wrote it. In terms of organization, I’d rather discuss how each topic (settings, models, etc.) relates to projects and apps than talk first about projects, then about

Case-insensitive email as username

Hello, I spent a good part of today implementing what must be the most common scenario for custom user models: case-insensitive email as username. (Yes. This horse has been beaten to death. Multiple times.) Since it was the first time I implemented a custom user model from scratch by myself,

Re: Case-insensitive email as username

2015-11-23 23:52 GMT+01:00 Carl Meyer : I've implemented the CITEXT-based solution a couple times; I think for a > PostgreSQL-based project it's the preferable option overall. > Perhaps we should add native support in contrib.postgres? I'm forseeing a small difficulty in terms

Re: Non-atomic migrations in Django?

I like the API as well. Surprisingly, I couldn't find a Trac ticket about this. -- Aymeric. 2015-11-24 16:39 GMT+01:00 Anssi Kääriäinen : > I don't see any problem with optional non-transactional migrations. So, +1 > for the idea and API. I haven't looked at the

Re: Keep django/django-old GitHub repo?

The real question is — did anyone remember that it existed before Tim brought it up? I’m pretty sure we can drop it. (For the more recent community members, it’s a git mirror of the original svn repo that predated the conversion of the official repo to git. We kept it around when we migrated.)

Re: annoyance with Python 3.2 support in Django 1.8

2015-11-26 5:22 GMT+01:00 Asif Saifuddin : > Python 3.2 should be removed as if any one use py3 should use 3.3+ or > better the latest stable. > Hi Asif, Your email sounds like the answer is obvious. It doesn't show that you thought about the use cases, especially those you

Re: annoyance with Python 3.2 support in Django 1.8

Hello Tim, Did you consider marking affected tests as expected failures on Python 3.2.6? I've done that on one of my projects which faced this exact issue (or a closely related one): https://github.com/aaugustin/myks-gallery/blob/master/gallery/test_admin.py#L199-L205 Best regards, --

Re: Code styling around URL in 404 pages shown with DEBUG = True

Hello James, This sounds reasonable. I would avoid using “root directory” to describe an URL because there isn’t usually a mapping between directories and URLs in Django projects. -- Aymeric. > On 26 nov. 2015, at 23:44, James Lu wrote: > > When you get a 404 with DEBUG

Re: is_authenticated as property

Django 1.8 worsens the situation significantly: {% if request.user.is_authenticated %} does the right thing in a Django template but is a security vulnerability in a Jinja2 template! We could implement a property that returns an object: - that is still callable, for backwards compatibility

Re: is_authenticated as property

2015-12-03 7:02 GMT+01:00 Josh Smeaton : > I think we should be asking.. why not? If there's not a good reason not > to, let's make it a callable and a property. > The original discussion dates back to 2008; back then I believe we were slightly more resistant to change,

Re: Validation of m2m

Hello Frederico, It appears that you're hitting the problem described in the "Avoid catching exceptions inside atomic!" warning on this page: https://docs.djangoproject.com/en/1.8/topics/db/transactions/#handling-exceptions-within-postgresql-transactions To obtain that sort of result, I suppose

Re: ORM difficulties

Hello, > On 5 déc. 2015, at 10:28, Raphael Gaschignard wrote: > > A behaviour that exemplifies this is that > queryset.annotate(foo=thing).annotate(bar=other_thing) is not the same as > queryset.annotate(foo=thing, bar=other_thing) given certain things. This goes > against

Re: Proposal to merge django-csp into contrib

Hello Thomas, > On 5 déc. 2015, at 23:23, Thomas Grainger wrote: > > I think merging django-csp into contrib would be a good fix for > https://code.djangoproject.com/ticket/15727 > I took a look at the pull request. I

Re: Backporting ticket 25548 into 1.9.x

> On 6 déc. 2015, at 10:49, James Bennett wrote: > > Thoughts? I don’t think anyone ever prevented a core dev who wanted to backport a commit from doing so — unless it carried a risk of backwards incompatibility, which doesn’t appear to be the case here. -- Aymeric.

Technical board report - 1.9 release cycle

Hello, As promised, here's the report from April 1st to December 1st, 2015. Activity was even lower than during the 1.8 cycle, which is excellent. For the first time, the board was asked by a commiter to make a technical decision (item 5). 1. April 8th, 2015: adding Preston Timmons to the

Re: Make template caching a feature of the Django template engine

Hello, I would suggest to enable the cached template loader by default when DEBUG = False and no ‘loaders’ options is specified. This is technically backwards-incompatible, but: - people who don’t usually configure it will get a free performance boost in production - people who do will be

Re: MOSS Award to Django

Hello, Unless I missed something, channels aren’t about websockets. They add asynchronous processing capabilities to Django. They aim at being compatible with any bidirectional protocol. Django should support common protocols out of the box and document a public API for third-party projects

Re: MOSS Award to Django

> Le 12 déc. 2015 à 23:10, Mitar a écrit : > > I would be > completely OK by supporting Websockets now on the transport level, but > the API level should understand and support backpressure. Hello Mitar, Yes, I fully agree with this way to frame the topic. I'm don't know how

Re: MOSS Award to Django

Hi Ben, Celery and channels don’t tackle the same problem. Celery is an asynchronous task queue. It is designed perform expensive work after responding to a HTTP request. At that point there is no possible communication with the browser. Channels is an asynchronous message framework. It

Re: Make template caching a feature of the Django template engine

On 18 déc. 2015, at 16:21, Tim Graham wrote: > Seems okay to me, but what about the point "It would also be useful to have > caching enabled in development so the template loading behaviour is (mostly) > the same in development as it is in production.” Would it be

Re: [Question] MySQL Microseconds stripping

Hello, > On 19 déc. 2015, at 09:21, Erik Cederstrand wrote: > >> Den 19. dec. 2015 kl. 13.15 skrev Cristiano Coelho >> : >> >> The issue is that every datetime column created has no microseconds (since >> they were created with django 1.7,

Re: [Question] MySQL Microseconds stripping

2015-12-20 22:57 GMT+01:00 Cristiano Coelho : > Thanks for the suggestion, I think that work around might just add too > much code, so I'm probably going the way of converting every datetime > column of every table to datetime(6) and afford the extra storage (and >

Re: FK constraints are not checked at the end of nested atomic blocks

Hello, When a question of "should Django do A or B here?" comes up, adding a setting to let the user choose is the last resort, because it's really a cop-out, not the default choice. Django explicitly creates FKs on PostgreSQL as DEFERRABLE INITIALLY DEFERRED in order not to check constraints

Re: FK constraints are not checked at the end of nested atomic blocks

2015-12-21 13:12 GMT+01:00 Anssi Kääriäinen : > The check_constraints operation is extremely expensive, and not suitable > for use at the end of savepoints. Ah. Too bad! -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django

Re: A community Poll

Hello Curtis, 2015-12-21 14:52 GMT+01:00 Curtis : > So aside from the obvious "preventing circular imports", what other > benefits do people see? > I'm afraid this is an example of "worse is better". String references to other models in FK definitions are one of the

Re: deprecate or undocument shorcuts.render_to_response()?

2015-12-22 18:34 GMT+01:00 Marc Tamlyn : > I'd be in favour of just undocumenting it for now. > I would be fine with either keeping it in the docs with a "you probably want render() instead" note or removing it from the docs. Then in a few years we can deprecate it. --

Re: structural & functional review of django documentation

On 27 déc. 2015, at 23:42, Tim Graham wrote: > In my view, Django's docs haven't strayed from the "topics", "reference", and > "how-to" division that we've had since 1.0 or so. I’ve been around for some time and, to be honest, I still have a hard time using this

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

At that point, I'd prefer picking an arbitrary length that makes sense for the underlying data rather than one based on MySQL's current limitations. Name length sounds like an reasonable proxy for username length. A quick Google search turns up

Re: delegating our static file serving

2015-12-31 12:52 GMT+01:00 Anssi Kääriäinen : > In my opinion one of the most important goals for Django is to make > deploying tiny projects securely and easily a trivial matter. We > aren't there right now. > +1 I'm maintaining three such sites (my wife's, my consultancy's

Re: delegating our static file serving

Hello Collin, > On 31 déc. 2015, at 23:44, Collin Anderson wrote: > > I feel like the insecure flag could get renamed to inefficient or something > like that. This view is insecure for serving user-uploaded files, for reasons Florian hinted at. Browsers “helpfully” get

Re: structural & functional review of django documentation

On 2 janv. 2016, at 05:48, Doug Epling wrote: > First is, has been, a discussion open for spectators but limited participants > to core members. Asside from its subject pertaining current state and future > path, all other details are above my pay grade. Hi Doug,

Re: URL dispatching framework: feedback requested

On 4 janv. 2016, at 13:24, Tim Graham wrote: > It looks to me like the rationale for the existing organization is that > everything in that module is designed to be used in a URLconf. I believe it is. However, as I said on the pull request, most users won’t reverse

Re: Request for Input: WSGI 2.0

Hi Cory, I’m not subscribed to web-sig but I read the discussion there. Feel free to forward my answer to the group if you think it’s useful. I have roughly the same convictions as Graham Dumpleton. If you want to support HTTP/2 and WebSockets, don’t start with design decisions anchored in

Re: Request for Input: WSGI 2.0

. Django currently contains such custom code. -- Aymeric. > On 5 janv. 2016, at 12:27, Cory Benfield <c...@lukasa.co.uk> wrote: > > On Tuesday, January 5, 2016 at 10:37:32 AM UTC, Aymeric Augustin wrote: > Hi Cory, > > I’m not subscribed to web-sig but I read the dis

Extending JSONField serialization

Hello, I’m using the JSONField provided by django.contrib.postgres for logging arbitrary data to PostgreSQL. For this use case, I’d like my data to be JSON serialized with as little fuss as possible. Unfortunately lots of things (dates, datetimes, decimals, etc.) aren’t natively

Re: Extending JSONField serialization

> On 5 janv. 2016, at 18:37, Tom Christie wrote: > >> Should JSONField accept additional kwargs to customize the encoder and the >> decoder? > > Quick take here: > > That sounds like a bit too much "cleverness" to me. The most obvious issue > it'd cause is putting

Re: Extending JSONField serialization

coding/decoding to integrate with third party systems is a regular > headache for me. I typically writ DRF serializers to take care of datetime > formatting, but a more general solution closer to the data layer would be > nice. > > Regards, > > Dwight > -- > &

Re: Vote on Jira as bugtracker

FWIW Jira seems to be an exception among bug trackers: some people really love it, others really hate it. It depends on who set it up and maintained it in the company where they used it. Since we don’t have a resident Jira expert, we run the risk that most of the Django community will fall

Re: slow migrations

As far as I understand, the CPU cost comes from generating a full set of model classes for each step of the migration history. That’s consistent with the profile sent by Florian. I usually end up throwing away the migration history and regenerating a new set of migrations when I get to that

Re: re-thinking middleware

+1 Great work. The only (and minor) concern I have is about allowing function-based middleware factories to return None. In the spirit of “there should be only one way to do it”, I would require raising MiddlewareNotUsed explicitly to disable a middleware. A middleware factory that returns

Re: Lazy operations refactor regression with abstract models #25858

Hello, On 9 janv. 2016, at 19:51, Shai Berger wrote: > So, I say, go for option 3. A field defined in a model in app1 takes app- > relative references in app1. I agree. We’re discussing an unintended regression. The discussion shows possible improvements in this area but

Re: deprecate CommaSeparatedIntegerField?

> On 21 janv. 2016, at 07:24, Josh Smeaton wrote: > > I'm in favour of making the change, just call it out as a backwards > compatibility. If I understand correctly, Oracle users encountering this issue would just have to adjust the field length? That sounds

Re: add prefered/default protocol in the sites framework #26079

> On 25 janv. 2016, at 14:19, Tim Graham wrote: > > I believe it's a common use case to import a copy of a production database > and examine it locally -- that's what I meant about portability. I’m not convinced by this argument because the data for the Site model will be

Re: deadlock risk from using cache a load time

> On 26 janv. 2016, at 00:43, John Bazik wrote: > > In db/models/base.py, in model_unpickle, I see this: > > if isinstance(model_id, tuple): > if not apps.ready: > apps.populate(settings.INSTALLED_APPS) > model = apps.get_model(*model_id) > >

Re: deadlock risk from using cache a load time

> On 26 janv. 2016, at 09:57, Florian Apolloner wrote: > > Revert yes, but a check like that should stay and maybe raise an error > instead of calling apps.populate. The following line, `apps.get_model(…)`, raises an exception when `not apps.models_ready`. --

Re: deadlock risk from using cache a load time

On 26 janv. 2016, at 14:40, Tim Graham wrote: > Something like "Models aren't loaded yet. Are you missing django.setup() in a > standalone script?". We’ve had this discussion before, cf. 8121860be4b9379d107959290e5748bbaf6de1fe ;-) The exception message could point to

Re: deadlock risk from using cache a load time

> Le 27 janv. 2016 à 00:59, Tim Graham a écrit : > > Regarding the original issue -- in Claude's use case, he says that calling > django.setup() before unpickling is not doable, as an external tool is doing > the unpickling of model data. Should we say that unpickling

Re: Replacing the contrib.sites Site model with a setting?

> On 29 janv. 2016, at 21:45, Tim Graham wrote: > > Do you think we'll be better off in the long run with a setting as opposed to > storing the data in the database? Yes. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django

Re: Replacing the contrib.sites Site model with a setting?

This is a valid use case, but not one django.contrib.sites (officially) supports, since it requires a constant SITE_ID setting. While Tim's suggestion doesn't cause a regression, it doesn't make this pattern easier to implement either. It's definitely worth considering. -- Aymeric. > Le 30

Re: [Review Request] Added support for database delegated fields (like AutoField)

Hello Owais, I had flagged this for review but it didn’t make it to the top of my list until today, sorry. The current approach adds 7 new APIs that only target the use case exposed in the ticket, which I find rather narrow. Some of these APIs (ignore_delegated) only exist to work around the

Re: [Review Request] Added support for database delegated fields (like AutoField)

> On 31 janv. 2016, at 22:55, Shai Berger wrote: > > Your message seems to be confusing the queryset API with the model-instance > API. Oops :-( Anyway, it seems that we agree on: - controlling this behavior in the query rather than in the field definition — this avoids

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

On 1 févr. 2016, at 12:20, Markus Holtermann wrote: > I think that links to 3rd party pages with grids, comparisons, pros'n'cons, > scattered all over Django's documentation aren't too helpful. I agree. I’m +0 on linking to Django packages on a page that talks about

Re: remove support for unsalted password hashers?

Adding a check for weak password hashers could be a good compromise to drive attention to the issue but make it reasonably easy to ignore it if you need MD5 for compatibility with other systems. -- Aymeric. > On 5 févr. 2016, at 21:11, Sergei Maertens wrote: > >

Re: remove support for unsalted password hashers?

y, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin wrote: > Adding a check for weak password hashers could be a good compromise to drive > attention to the issue but make it reasonably easy to ignore it if you need > MD5 for compatibility with other systems. > > -- >

Re: thinking about the admin's scope and its description in the docs

+1 -- Aymeric. > On 17 févr. 2016, at 18:16, Marc Tamlyn wrote: > > That looks like a good balanced message to me. > > On 17 February 2016 at 16:57, Tim Graham > wrote: > Here's another try for the docs: > > One of

Re: Add warning or prohibit module level queries?

Hello, To the best of my knowledge, in Django 1.10, the window for such problematic database queries will shrink to the interval between the moment `apps.models_ready` becomes `True` and the moment `apps.ready` becomes `True`. That’s when AppConfig.ready() methods execute. In Django 1.9, if a

Re: Improving django.setup() and app loading performance

Hi Rich, On 26 févr. 2016, at 16:36, Rich Jones wrote: > I'd love to discuss ideas for performance optimizations to Django's setup > method. In my opinion, the first concrete step would be to measure how much time is spent executing Django code rather than importing

Re: Making max_length argument optional

Hello, This thread is getting long. It contains lots of valid arguments. In the interest of seeking consensus, here’s a tentative summary. Problem Typing `foo = models.CharField(max_length=100)` gets old quickly. Can we skip the `max_length` argument in many cases? Constraints Character

Re: Add support for relative imports in django.conf.urls.include()?

I’m +0 on this change, for consistency with Python’s import statement. -- Aymeric. > On 29 Feb 2016, at 14:17, Tim Graham wrote: > > > For example, within myproject.urls: > > urlpatterns = ( > url(r'', include('.myapp.urls')), > ) > > .. becomes

Re: Improving django.setup() and app loading performance

Hello Rich, > On 01 Mar 2016, at 01:44, Rich Jones wrote: > > I think the interesting things to explore would be: > - Loading apps in parallel > - "Pre-loading" apps before app deployment, then loading that cached state > at runtime. I guess I'd need to know more about

Re: Copy-from-base inheritance

Hello, The “locally declared field gets overriden by parent definition” behavior shown in your example looks counter-intuitive to me. Inheritance means that children inherit and possibly specialize their parent’s behavior, not that the parent overrides the child. Best regards, -- Aymeric.

Re: Copy-from-base inheritance

. > On 02 Mar 2016, at 10:25, Joakim Saario <saario.joa...@gmail.com> wrote: > > I'm sorry, this is a typo, local fields overrides parent fields of course. > Look at the patch. > > Den onsdag 2 mars 2016 kl. 08:19:23 UTC+1 skrev Aymeric Augustin: > Hello, > >

Re: Copy-from-base inheritance

gt; Den onsdag 2 mars 2016 kl. 10:52:07 UTC+1 skrev Aymeric Augustin: > In that case, I believe this is the ticket you’re looking for: > https://code.djangoproject.com/ticket/24305 > <https://code.djangoproject.com/ticket/24305> > > There seems to be some activity on t

Re: Copy-from-base inheritance

Hi Joakim, On 03 Mar 2016, at 11:03, Joakim Saario wrote: > The problem is that django hijacks the class-inheritance feature of python > and uses it soley > for relational inheritance. I understand that you would like each model class to have its own table with all

Re: Proposal: django.contrib.mysql

Hi Adam, django-mysql has a rather large API surface. I think the first step would be to make a list of the most stable and generally useful bits that are candidate for inclusion in Django and to write that list down in a DEP. The fields, functions, lookups, and aggregates are good candidates.

Re: TransactionManagementError is raised when autocommit …

If you do what Simon and I suggest, you should get the result you just described. If you don’t, please explain what happens. Within a transaction — and disabling autocommit means you’re within a transaction — transaction.atomic() uses savepoints. Note that in Django 1.6, after

Re: TransactionManagementError is raised when autocommit …

Hi Tore, > On 05 Mar 2016, at 20:41, Tore Lundqvist wrote: > > Regardless of the particular problem I have got shouldn't it be possible to > disable Djangos transactional management if you want to? It's possible. It’s documented.

Re: TransactionManagementError is raised when autocommit …

Hi Tore, I’ve been meaning to check whether your use case was supported, because it should be. I’m sorry, it took me a few days to find the time to investigate. While I was testing, I produced an exception which looks similar to the problem you originally reported:

Re: TransactionManagementError is raised when autocommit …

On 11 Mar 2016, at 10:28, Tore Lundqvist wrote: > Given MySQL’s interesting approach to transactional integrity, you can call > transaction.set_rollback(False) after a query that failed with an > IntegrityError and keep going. > > You can't use set_rollback() outside an

Re: Value of tightening URLValidator/EmailValidator regular expressions?

> On 15 Mar 2016, at 03:51, Markus Holtermann wrote: > > I'd go with the HTML5 validator. Indeed, it would be a good idea to align the behavior of and Django’s validation. Currently a@b passes the former but not the latter. -- Aymeric. -- You received this

Re: MySQL data loss possibility with concurrent ManyToManyField saves

I agree with Karen. -- Aymeric. > On 18 Mar 2016, at 22:15, Karen Tracey wrote: > > This is the 2nd major issue I can recall caused by MySQL default of > REPEATABLE READ transaction isolation level. I think Django should simply > switch itself to a default of using READ

Re: MySQL data loss possibility with concurrent ManyToManyField saves

On 21 Mar 2016, at 01:25, Cristiano Coelho wrote: > > What performance changes can you expect doing this change? It is probably > that default on MySQL for a good reason. Barring implementation weirdness, reducing the isolation level is supposed to improve

Re: MySQL data loss possibility with concurrent ManyToManyField saves

We’ve had, and known about, such problems for so long that I’m also inclined not to make that change in already released versions. -- Aymeric. > On 21 Mar 2016, at 12:33, Anssi Kääriäinen wrote: > > This being MySQL I wouldn't be surprised if changing the isolation > level

Re: MySQL data loss possibility with concurrent ManyToManyField saves

Hello, > On 21 Mar 2016, at 12:01, hcharg...@medici.tv wrote: > > In my opinion, the fix should not be to set a different default isolation > level, as that could trigger other problems that may be very hard to find. I > was lucky to find this one. I think that Django should find sequences of

Re: MySQL data loss possibility with concurrent ManyToManyField saves

On 21 Mar 2016, at 15:02, Hugo Chargois wrote: > > But here, we have "two non-conflicting updates (no-ops, even) causes data to > be lost". I bet no one would call this safe. Yes, this one was clearly a bug (and, if I understand correctly, it was resolved by a

Re: relative path in {% extends "...base.html" %} like relative import

On 24 Mar 2016, at 01:07, Tim Graham wrote: > Asking again... I am not sure if the Django Template Language should evolve > new features like this. Is there any prior art in Jinja2? Absent any other > +1's, I guess I would be more comfortable accepting the feature if so.

Re: Revisiting lazy middleware initialization

On 24 Mar 2016, at 17:39, David Evans wrote: > > Currently, middleware is initialized lazily on serving the first request, > rather than on application start. There may well have been good reasons for > this historically, but I don't think they apply any longer. Indeed,

Re: Should DecimalField have special rounding to make float assignments match string assignments?

I have three ideas about this. 1) In my opinion, assigning a float to a decimal field is a programming error. Sadly Python doesn’t raise an exception in that case. >>> decimal.Decimal(2.15) Decimal('2.149911182158029987476766109466552734375') So Django has to support it as well.

Re: Should DecimalField have special rounding to make float assignments match string assignments?

..create_decimal_from_float method — which relies on a specific context https://docs.python.org/3.5/library/decimal.html#decimal.Decimal.from_float I assume the latter will be more convenient for low level control. -- Aymeric. > On 05 Apr 2016, at 16:17, Aymeric Augustin > <ayme

Re: Add documentation to address OWASP Top 10?

That was my thinking as well. This is a basic topic when it comes to web security. We can point to the OWASP 10 but I don’t think it’s reasonable cram a complete course about web security into Django’s documentation, let alone maintain it. Django’s docs will never contain everything one may

Re: Vendoring Select2

I’m OK with this. It's a reasonable solution. -- Aymeric. > On 06 Apr 2016, at 15:25, Johannes Hoppe wrote: > > Hi, > > as promised I started working on an autocomplete field for > `django.contrib.admin` as a more convenient alternative to `row_id_fields`. > > We

Re: Sqlite 3.12 breaks the Django test suite

This other ticket about a SQLite segfault may or may not be related: https://code.djangoproject.com/ticket/24080 -- Aymeric. > On 07 Apr 2016, at 13:00, Raphael Hertzog wrote: > > [ CCing an upstream developer of SQlite too ] > > Hello, > > I did not want to open a ticket

Re: Sqlite 3.12 breaks the Django test suite

For the record, the discussion continues here: https://www.sqlite.org/src/info/7f7f8026eda38 -- Aymeric. > On 07 Apr 2016, at 18:27, Florian Apolloner wrote: > > mkdir ~/sqlite > cd ~/sqlite > git clone g...@github.com:django/django.git > git clone

Re: Making Django more PaaS-friendly

We have a chicken’n’egg problem to support third party database backends with dj-database-url’s current API: - It is each backend’s responsibility to parse the URL and extract the configuration for a given database. - Parsing the URL is a prerequisite to figure which database backend to pick

Re: Making Django more PaaS-friendly

> On 11 Apr 2016, at 19:39, Curtis Maloney wrote: > > 1. All env vars can have a fallback value (the method in my case) > 2. You can mark an env var as not having a fallback value, and it will raise > an error at start up if not set. There’s an additional complexity here.

<    3   4   5   6   7   8   9   10   11   >