Re: MySQL data loss possibility with concurrent ManyToManyField saves

Le mardi 22 mars 2016 00:11:31 UTC+1, Shai Berger a écrit : > I disagree. The ORM cannot keep you safe against MySql's REPEATABLE READ. >> Incidentally, to prove my point, >> this has been changed in Django 1.9 and data-loss doesn't happen anymore, >> in that same default isolation level. >>

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

> > I see you created a pull request: >> https://github.com/django/django/pull/6318 >> > Syntax for relative path was changed from ... to ./../ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To

Re: [GSoC 2016]Proposal: Validity check at client and dynamic form framework

On 20.03.2016 14:59, Lover Di wrote: Hi, I have been working for preparing a proposal about a new feature for Django. I'm posting my draft proposal to Gist and want to know my idea is OK or not. So I can proceed with the right approach. Any suggestions or advice are welcome. Abstract of

help

hi i am S TIRUMALA RAO and really interested in django projects.if anyone could help me out with what has to done. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop

Re: help

Is this about Google Summer of Code (if so, it's too late to start a proposal) or something else? If it's about contributing to Django, please see https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/ for advice. On Tuesday, March 22, 2016 at 8:32:40 AM UTC-4, SANGAPU

Re: Working on a profiling/benchmark tool for the django template language. Looking for feedback on my work so far.

Did FunkyBob indicate he was interested in mentoring this project? In my view, the idea isn't so important now that we have Jinja2 integration but I didn't remove it from the idea list since I didn't get a definitive answer about that. On Saturday, March 19, 2016 at 8:41:33 AM UTC-4, Quentin

Re: Proposal on Custom Indexes - Google Summer of Code

Instead of aiming for one huge patch to be merged at the end of the summer, I'd suggest to think about whether you can break up the work in chunks that can be merged incrementally. This should decrease the risk that comes with a huge patch going stale and makes code review much easier. It's

Re: GSoC 2016: Draft Proposal on SQLAlchemy Integration with django

I've never used SQLAlchemy myself, so I can't really comment on it without the technical details of what you would actually be doing. On Friday, March 18, 2016 at 8:11:12 AM UTC-4, Asif Saifuddin wrote: > > Hi, > > I have been working for preparing a proposal on SqlAlchemy integration > with

Re: [GSoC 2016]Proposal: Validity check at client and dynamic form framework

I agree with Jani that you should think about trying to make the proposal accommodate different JavaScript frameworks. You might look at https://github.com/jrief/django-angular, for example, for inspiration. Just thinking about what problems Django should be trying to solve, I'm wondering if

Re: GSoC 2016: Draft Proposal on SQLAlchemy Integration with django

Hi Tim, I have been sick for few days so couldn't work fully on the proposal. To give you have some idea on what I will be doing: * creating a django-sqlalchemy package like flask-alchemy/pyramid_alchemy which user can use on any regular django project under installed app. The package will

Re: Feedback on Django Channels

I do think encrypting the Redis channel layer is something we should offer: Redis out of the box doesn't do transport-layer encryption, which is going to make Channels a hard sell to anyone with any for of regulatory/compliance requirements. [1] I think probably Fernet [2] is the right way to do

Re: Feedback on Django Channels

> On Mar 22, 2016, at 1:24 PM, Jacob Kaplan-Moss wrote: > > I do think encrypting the Redis channel layer is something we should offer: > Redis out of the box doesn't do transport-layer encryption, which is going to > make Channels a hard sell to anyone with any for of

Re: Feedback on Django Channels

Indeed, we run Redis over TLS tunnels at work to fulfill this requirement, so I know transport security is required, but at the same time reinventing it might be more work than we need - would you trust our internal symmetric encryption system, or go for TLS tunnels instead? Still, if we want to

Re: Feedback on Django Channels

On Tue, Mar 22, 2016 at 1:44 PM, Andrew Godwin wrote: > Indeed, we run Redis over TLS tunnels at work to fulfill this requirement, > so I know transport security is required, but at the same time reinventing > it might be more work than we need - would you trust our internal

Re: Feedback on Django Channels

On Tue, Mar 22, 2016 at 4:04 PM, Michael Manfre wrote: > > If not provided out of the box, there needs to be a supported way of > wiring in encryption. The security/compliance person at my job stated that > only securing the transport was not good enough for our compliance >

Re: MySQL data loss possibility with concurrent ManyToManyField saves

On Tuesday 22 March 2016 11:57:03 Hugo Chargois wrote: > > I'm unsure that your relentless rant against MySQL is useful in this topic. I'm sorry if anyone sees it as a rant. It is intended as a technical argument that MySql's REPEATABLE READ is unsuitable for use as a default by Django. > >

Re: Improving MSSQL and Azure SQL support on Django

Hey Tim, We are continuing to follow up with Michael and have reached out to Michiya as well. We have not abandoned the idea of providing engineering resources either, and are still working out the logistics with Michael as he will help direct our efforts. We are syncing again in mid-April

Using auth stuff without installing the auth app

I like to use the authentication machinery in Django, without explicitly putting 'django.contrib.auth' in INSTALLED_APPS. This prevents a bunch of unused tables from being creating in the database. This was possible in earlier version of Django. In 1.8, a spurious warning was generated, but