Re: Improved Error Reporting in Django - GSoC

Hi Andrew As about the silent template failure I was not very sure if it was a deliberate design decision, but since it a deliberate design decision I would not like to change it. Since I did both the backend and template editing, it appeared to me that some error should have come. But I

Re: auth.User refactor: reboot

Hi I have just been using Django for the last 4 months, and the application I developed needed an extensive UserProfile module. It needed things such as 1. Ability to log in via both email and username 2. Ability to link multiple social accounts with the same user account (the

Re: auth.User refactor: reboot

On Sat, Mar 17, 2012 at 5:59 AM, Russell Keith-Magee wrote: > Ok - I've been keeping quiet on this; partially due to the same tone issues > that you've described, but also because I don't have a huge amount of spare > time at the moment, and I don't want to be the

Re: Improved Error Reporting in Django - GSoC

Hi Andrew I am going through the errors on this page https://code.djangoproject.com/wiki/BetterErrorMessages particularly the django.db errors. The error which is listed on the page might not be updated For the error message OperationalError: Unable to close due to unfinalised statements The

Re: auth.User refactor: reboot

On 20/03/2012, at 8:38 PM, Tom Evans wrote: > >> * It's completely backwards compatible. >> >> If you've got an existing app with normal ForeignKeys to auth.User, >> the app will continue to work, without any migrations, as long as >> the rest of your project uses auth.User. It will also

Re: auth.User refactor: reboot

On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee wrote: > > On 20/03/2012, at 8:38 PM, Tom Evans wrote: >> >>>  * It's completely backwards compatible. >>> >>> If you've got an existing app with normal ForeignKeys to auth.User, >>> the app will continue to work,

auth.User: The abstract base class idea

There have been various proposals about replacing the User class with an abstract base class. Ian Lewis has a semi-workable version at http://ianlewis.bitbucket.org/django-newauth/index.html but its proposal met with resistance in part because there's not a great migration path from existing apps.

Re: auth.User: The abstract base class idea

On Tuesday, March 20, 2012 at 11:25 AM, Alex Ogier wrote: > There have been various proposals about replacing the User class with > an abstract base class. Ian Lewis has a semi-workable version at > http://ianlewis.bitbucket.org/django-newauth/index.html but its > proposal met with resistance in

Re: auth.User: The abstract base class idea

> This is pretty much exactly what django-primate does, except it includes a > special metaclass to allow > overriding of default fields. Yeah, that is the basic idea. I think that permissions and associated code should be moved from UserBase to live directly on auth.User or in a mixin of their

[GSOC 2012] Customizable serialization

Hi, My name is Piotr Grabowski. I'm last year student at the Institute of Computer Science University of Wrocław (Poland). I want to share with you draft of my GSOC proposal. http://pastebin.com/ePRUj5HC PS. Sorry for my poor english :/ -- Piotr Grabowski -- You received this message

Re: auth.User refactor: reboot

> However not all databases have this same behavior when trying to insert a > string that is longer than > the field allows. This means that for a certain subset of Django developers > if they didn't read the > releases note, or just missed that section of it that Django would not > validate

Re: auth.User refactor: reboot

> Would something like the following alleviate that problem? > > class User(models.Model): >if settings.USE_LONG_USER_FIELDS: >username = models.CharField(max_length=255, unique=True, ...) >else: >username = models.CharField(max_length=30, unique=True, ...) >... Maybe,

Re: Improved Error Reporting in Django - GSoC

On 20/03/12 07:18, Sachin Gupta wrote: Could you guide me what number of error fixes would be good work for GSOC proposal. Also if there are any class of Django errors that are of greater concern (like django.db) There's no clearly defined "number" that would be good - we'll be looking at

Re: auth.User refactor: reboot

On Tuesday, March 20, 2012 at 1:07 PM, Nan wrote: > > > However not all databases have this same behavior when trying to insert a > > string that is longer than > > the field allows. This means that for a certain subset of Django developers > > if they didn't read the > > releases note, or just

Re: auth.User refactor: reboot

On Tue, Mar 20, 2012 at 5:17 PM, Alex Ogier wrote: >> Would something like the following alleviate that problem? >> >> class User(models.Model): >>    if settings.USE_LONG_USER_FIELDS: >>        username = models.CharField(max_length=255, unique=True, ...) >>    else: >>    

Re: auth.User refactor: reboot

> On Tuesday, March 20, 2012 at 1:07 PM, Nan wrote: >> >>> However not all databases have this same behavior when trying to >>> insert a string that is longer than >>> the field allows. This means that for a certain subset of Django >>> developers if they didn't read the >>> releases note, or

Re: auth.User refactor: reboot

On Tue, Mar 20, 2012 at 1:17 PM, Alex Ogier wrote: >> Would something like the following alleviate that problem? >> >> class User(models.Model): >>    if settings.USE_LONG_USER_FIELDS: >>        username = models.CharField(max_length=255, unique=True, ...) >>    else: >>    

Re: auth.User refactor: reboot

On Tue, Mar 20, 2012 at 5:41 PM, Donald Stufft wrote: > What Alex said. If it was _just_ the username then you'd have a good > argument for > a setting like that. However there's username, email, some people want to > add > fields, some want to get rid of, or combine

Re: auth.User refactor: reboot

A bit of an odd question-- What practices have other packages adopted? For example, I was playing with ASP.NET last weekend to help out a friend and found their decoupling of authentication from the database to be rather pleasant. Is it possible to add a layer of indirection. In some sense, I

Re: auth.User refactor: reboot

20.03.2012 20:40, william ratcliff ?: > To facilitate these different cases, can we have a pluggable > "Authentication Service" where the user provides a "credential" which > then returns a result of whether the credential is valid or not?We > could then implement a few "standard"

Re: auth.User refactor: reboot

> > > > On Tuesday, March 20, 2012 7:08:49 AM UTC-7, Tom Evans wrote: > >> On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee >> wrote: >> > >> > On 20/03/2012, at 8:38 PM, Tom Evans wrote: >> >> >> > Personally, I'd be in favor of option (3), mostly because what the last >> 6 years has

Re: [GSOC 2012] Customizable serialization

On 20 March 2012 17:50, Piotr Grabowski wrote: > Hi, > > My name is Piotr Grabowski. I'm last year student at the Institute of > Computer Science University of Wrocław (Poland). I want to share with you > draft of my GSOC proposal. Hi, nice to meet you :) > >

Re: [GSOC 2012] Customizable serialization

I like the project and am +1 on Łukasz's points #1 and #3. Meta.fk_level looks very useful though. For example if models have parent/sibling relationships or otherwise relate to themselves and you can't guarantee the relationships are acyclic. Definitely a worthy project. -Alex Ogier -- You

Re: [GSOC 2012] Customizable serialization

Actually, thinking about it a bit more, it seems fk_level is bound to be a significant source of untested edge-case behavior. Every time the limit is reached, there will be an unexpectedly flat relationship that a naive recursive deserializer may choke on. I would be +1 on a fail-fast version of

Re: auth.User refactor: reboot

On 21/03/2012, at 1:49 AM, Бачериков Вячеслав wrote: >> > There other way do do this. > For example tunning of User model can done by configuration, like that: > > EXTENDED_USERMODEL_SETTINGS = {'email': >{'uniq':True,'max_length':255, >

Re: auth.User refactor: reboot

On 20/03/2012, at 10:27 PM, Donald Stufft wrote: > > On Tuesday, March 20, 2012 at 10:08 AM, Tom Evans wrote: > >> On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee >> wrote: >>> >>> The key point here is that we're not forcing every Django user to discover >>>

Re: auth.User refactor: reboot

On 21/03/2012, at 2:00 AM, Tom Evans wrote: > On Tue, Mar 20, 2012 at 5:41 PM, Donald Stufft > wrote: >> What Alex said. If it was _just_ the username then you'd have a good >> argument for >> a setting like that. However there's username, email, some people want to >>

Re: auth.User refactor: reboot

On 21/03/2012, at 4:57 AM, ptone wrote: > > > > The key point here is that we're not forcing every Django user to discover > > by accident that they need to run an ALTER TABLE statement in order for > > their projects to keep working. The opt-in nature of the change is key. > > > > > > I

Re: [GSOC 2012] Customizable serialization

W dniu 20.03.2012 22:00, Łukasz Rekucki pisze: 1) The Meta.structure things looks like a non-starter to me. It's a DSL inside a DSL. I'm also not sure what it actually does - you already have all those @attribute decorators, why repeat their names in some string? One of my principle

Re: [GSOC 2012] Customizable serialization

>    One of my principle was to let user define any possible structure. > Ex > > > > > Django > > > > > > 1. With Meta.structure you can do: > def name >    return Django > structure="a[b[c[name__field]]] > > 2. Without: > def a >    return BFieldSerializer > class BFieldSerializer >    

RE: Complex aggregate and expression composition.

I took a quick look at your patch. I don't have more time now, so just some quick comments: - In general, the approach where aggregates are just expressions sounds and looks valid. - I would not worry about the extra time used in djangobench. However, profiling why there is extra

release blocker in 1.4rc2 ?

Hi all, I just opened https://code.djangoproject.com/ticket/17944, not sure it's should be marked as release-blocker, please could some core-developer check it ? The ticked has 1.4beta1 release, there is no rc2 in the list Cheers Stefano P.S. if this email is not compliant with the ticket

Re: auth.User refactor: reboot

On Tuesday, March 20, 2012 8:38:36 AM UTC-4, Tom Evans wrote: I'm not -1 on pluggable auth models, I just think it is orthogonal to > the real issue. A 'fix' which doesn't allow longer email addresses by > default in d.c.a is not a fix as far as I am concerned. > We could debate what it means to

Re: auth.User refactor: reboot

On 21/03/2012, at 12:23 PM, Clay McClure wrote: > On Saturday, March 17, 2012 8:52:01 PM UTC-4, Russell Keith-Magee wrote: > > The only way I can see around this problem is to come up with a way for > ForeignKey(User) to transparently become an effective > LazyForeignKey('auth.User'). > > I