On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant <l.plant...@cantab.net> wrote: > On 09/03/12 14:49, Tom Evans wrote: > >>> Yes, since no one needs it. Okay no one isn't true, but no one (for true >>> this time) who needed it stepped up and said "I'll implement it and see that >>> it ends up in trunk" >>> >> >> I'm sorry, that completely mis-characterises the situation. Lots of >> people want this, but every single time this has been brought up since >> I started using django (1.0), a core dev or BFDL has explicitly ruled >> it out, saying "we cannot do this, requires schema migration, we'll >> look at it for the next version". > > This is not true. There have been times when we have said we cannot > consider it right now, and that a solid proposal should be brought up at > the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the > core developers can look at it. > > And every time, the proposal has either been missing or simply not been > adequate - for example, the GSoC 2010 and 2011 proposals regarding this. > Russell gave detailed feedback on why these solutions were not adequate > [1], and at other times has provided feedback on possible strategies > [2]. And the people who went away to work on the problem have gone > silent or admitted defeat. One presumes they fixed their immediate > problem in a way that would not be a general solution, and moved on, and > that is perfectly understandable. A adequate solution to this is very > hard, and probably requires solving several other big problems first > (like at least one of lazy foreign keys/virtual models/database migrations). > > It isn't, however, impossible. Our definition of 'need' is that someone > is sufficiently motivated to overcome the obstacles, and contribute a > solution that works for other people as well as themselves. > > Regards, > > Luke > > > [1] http://goo.gl/swTpr > > [2] http://goo.gl/7p1JN >
I disagree. There are small problems with the User model that have not been fixed. Every proposal you've listed does not address these issues, but instead looks to find ways of replacing the base user object, which is a complex and difficult project. There is a reason why these are the proposals. Every time someone proposes fixing these minor bugs, the cry from on high is that instead, d.c.auth will be overhauled to allow for more customization by the project, immediately increasing the scope and complexity. But this fabled d.c.auth2 never appears. In fact, your reply alludes to this. We're talking about why a field is too short to contain valid values, and you suggest that the solution inevitably will involve "lazy foreign keys/virtual models/database migrations" - it's changing one line, and adding a comment to relnotes! We may have to agree to disagree on how easy some of these things are to fix. Lets look at one isolated aspect. The User email field in d.c.auth is too short. Emails can be up to 248 characters long, and d.c.auth only allows 75. Clearly, this is a bug, is wrong and should be fixed. How can we fix it? We can alter the length of the field in the model definition. What problems does this bring? Users who do not manually update their database will not be able to store longer length emails, and will get 'strange effects' when they try - either silent truncation, or database integrity errors. How can we mitigate this for users who refuse to update? Provide a compat shim that resets the email length to that in 1.3, and immediately mark it PendingDeprecation. Users who read the relnotes and don't want to change their DB can use the shim, and have a clear expectation of when they must have updated their database. I still think these bug fixes are paralysed by a fear of change, and a desire to engineer a solution that is every thing to every man. Lets just fix these glaring bugs… Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
