Re: Improving MSSQL and Azure SQL support on Django

On Wednesday, September 2, 2015 at 3:05:23 PM UTC-7, Ramiro Morales wrote: > > Hi all, > > On Fri, Aug 21, 2015 at 2:39 PM, Meet Bhagdev > wrote: > > Hi Django Committers, > > > > > > > > My name is Meet Bhagdev, I work in the Database Systems engineering team > at

Re: AbstractUser hierarchy and email-based-users

On Wed, Sep 2, 2015 at 10:29 PM, Tim Graham wrote: > Russ tried to complete the "EmailUser" solution for 1.7, but if I remember > correctly, there was some issue with testing that couldn't be easily > resolved. > >

Re: Improving MSSQL and Azure SQL support on Django

Hi Tim, I will definitely be driving the initial planing and will help lay out the ground work. There will be other engineer(s) who will work on contributing to third party adapter(s) and the Django project(eventualy). But first, we need to figure out the ask and the nature of work required.

Re: Improving MSSQL and Azure SQL support on Django

Hi all, On Fri, Aug 21, 2015 at 2:39 PM, Meet Bhagdev wrote: > Hi Django Committers, > > > > My name is Meet Bhagdev, I work in the Database Systems engineering team at > Microsoft in Seattle, WA. My focus is the APIs used to connect to and use > Azure SQL Database and SQL

Re: Validate domains against IDNA2008 instead of IDNA2003?

Hi, Am Wed, 2 Sep 2015 14:35:22 -0700 (PDT) schrieb Tim Graham : > However, python standard lib [ > https://docs.python.org/3/library/codecs.html?highlight=idna#module-encodings.idna > > only offers IDNA2003] validation in , and one have to use [ >

Validate domains against IDNA2008 instead of IDNA2003?

Quoting this ticket: https://code.djangoproject.com/ticket/25337 """ IDNA domains validation is a mess, anyway, it's going forward, and IDNA2008 refines IDNA2003 proposal to better define what is a valid IDN domain and what is not. ICANN/IANA [

Re: Ability to migrate other applications

> My main concern is not with the complexity of your proposed patch but with > committing to supporting a new API that solves a problem that can already > be solved a different way (albeit maybe less elegantly). Anyway, I don't > want to speak definitely about the issue, but it seems like if

Re: Ability to migrate other applications

My main concern is not with the complexity of your proposed patch but with committing to supporting a new API that solves a problem that can already be solved a different way (albeit maybe less elegantly). Anyway, I don't want to speak definitely about the issue, but it seems like if we keep

Re: Ability to migrate other applications

> > I think if I were doing this, I would go the route of using > MIGRATION_MODULES and copying the reusable app's migrations into it, then > adding my own migrations. Yes, this would require copying any new > migrations from an updated version of the app, > Yes that sounds like a lot of

Re: WIKI_VIEW privileges are required to perform this operation. You don't have the required permissions.

This issue turned out to be a bug in Trac, fixed by upgrading to the latest version. Details in https://github.com/django/code.djangoproject.com/issues/58. On Monday, August 31, 2015 at 8:35:30 AM UTC-4, Tim Graham wrote: > > Hi, as far as I know, we haven't banned anyone in Trac. We did

Re: Ability to migrate other applications

I think if I were doing this, I would go the route of using MIGRATION_MODULES and copying the reusable app's migrations into it, then adding my own migrations. Yes, this would require copying any new migrations from an updated version of the app, but I am a bit nervous about adding more

Re: Improving MSSQL and Azure SQL support on Django

Hi Meet, Will you be the primary contributor/maintainer from Microsoft of this project or will their be other engineers at Microsoft involved? I'd like to understand the bus factor on your side and how much time resources you plan to provide. To give you an idea of how our community works

Re: AbstractUser hierarchy and email-based-users

Russ tried to complete the "EmailUser" solution for 1.7, but if I remember correctly, there was some issue with testing that couldn't be easily resolved. https://github.com/django/django/compare/master...freakboy3742:emailauth Anyway, if that issue is still blocked, it looks like the

Re: AbstractUser hierarchy and email-based-users

I'm +1 on this. On Sep 2, 2015 10:31 AM, "'Hugo Osvaldo Barrera' via Django developers (Contributions to Django itself)" wrote: > Hi, > > I've worked on several apps where users don't have a username, and > instead require a unique email. Every time, I've used

Re: Django Admin - ModelAdmin exclude

I agree that there are a lot of of hooks in the admin and we might need to better document them or remove unneeded or maybe make a revolution :) But, with the current api and scheme, having get_exclude is more of the expected behavior of Django and i think it should be implemented. What we

AbstractUser hierarchy and email-based-users

Hi, I've worked on several apps where users don't have a username, and instead require a unique email. Every time, I've used a similar custom user model which extended AbstractBaseUser, PermissionsMixin. I then had to copy-paste several fields from AbstractUser into my custom user (either because