On Wed, Mar 21, 2012 at 1:48 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
I agree - that's why my original proposal was to make the LazyForeignKey
> explicit -- that makes the adoption process opt in. Yes, this means that
> apps need to be modified and advertised to be "1.5
> swappabl
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 e
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 "
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 explored this a bit and found that, since the binding of
Fo
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 po
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 tim
> 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
> def
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
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 t
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
>> add
>> fields, some want
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
>>> by accident that they need
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,
>
Hello all,
Since even before I saw Alex Gaynor's presentation "I hate the Django ORM"
(the one with the `Sum(F("end_time") - F("start_time"))` query), the problem
of complex aggregates and expressions has vexed me. So, I figured I would
try to solve it.
Originally, I started this trying to pursue
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 th
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
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 :)
>
> http://pastebin.com/ePRUj5HC
IMHO,
>
>
>
> 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 taught
It seems most of the errors on this page
https://code.djangoproject.com/wiki/BetterErrorMessages are very old. It
states that if the attribute enctype="multitype/form-data" is not sent then
the following error comes up
TypeError at ...
string indices must be integers
However if this is the cas
> 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" authentication plugins, such as username/password,
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" authentic
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
On Tue, Mar 20, 2012 at 6:02 PM, Donald Stufft wrote:
> So you fix the problem for the people who agree that username should be
> longer, and that email
> should be longer, but not the people who feel that email should be longer
> but username is fine?
>
> Those settings do not feel any cleaner to
On Tuesday, March 20, 2012 at 2:00 PM, Tom Evans wrote:
> On Tue, Mar 20, 2012 at 5:41 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> 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
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 fields. Ideally any change wou
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:
>> username = models.C
> 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
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:
>> username = models.C
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
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 you
> 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,
> 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 th
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 becau
> 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 ow
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 pa
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.
On Tuesday, March 20, 2012 at 10:08 AM, Tom Evans wrote:
> On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee
> mailto:russ...@keith-magee.com)> wrote:
> >
> > On 20/03/2012, at 8:38 PM, Tom Evans wrote:
> > >
> > > > * It's completely backwards compatible.
> > > >
> > > > If you've got an
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, without any migrations, as long
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 co-exi
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
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 person who makes a bunch of
>
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 social
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 would
42 matches
Mail list logo
