Re: four NoSQL backends you want? :)

[Russell Keith-Magee]

On Sun, Sep 26, 2010 at 1:24 AM, Waldemar Kornewald
 wrote:
> On Sep 25, 4:21 pm, Russell Keith-Magee 
> wrote:
>> My reason for wanting this is that I'm simply not an expert in any of
>> these backends. I know SQL quite well, but I haven't had occasion to
>> try out other backends in depth. I can judge the technical merits of a
>> patch based on what I know, but I don't want to make a judgement based
>> on incompletely knowledge. I need to rely on those that I know and
>> trust to give me confidence that nothing has been missed.
>
> This is really the biggest problem. If you work in a company where
> your lead developer or manager doesn't know enough about the
> technology and for that reason wants to have a huge amount of analysis
> and review how are you going to get anything done? You'd surely call
> such a company dysfunctional.

OK - I call bullshit.

What you appear to be saying is that when a person in a management
position knows that they don't have expertise in a particular area,
the appropriate response is to find the first person that volunteers a
solution, and accept their answer as gospel truth?

I am well skilled in SQL. I am probably one of a handful of people who
can call themselves an expert on the inner workings of Django's ORM. I
am an expert on the mental model that Django's ORM is trying to push,
and the sorts of architectural decisions that will and won't be
acceptable to the core.

I am not well skilled in NoSQL. I have tinkered enough to understand
the broad issues, but I don't have particular expertise in any of the
backends. I'm interested in adding NoSQL support to the core of
Django. Therefore, I'm calling for people who *do* have expertise, and
whose expertise I know I can trust, to provide direction that nothing
important has been missed in the analysis.

Calling for expertise when you know you're lacking isn't dysfunctional
management. It's responsible management.

Also, you say a "huge" amount of analysis -- at the moment, *any*
analysis would be a step in the right direction. I haven't seen *any*
summary of the features that are and are not supported by various
backends. The summary pages that I directed your attention to (for
CSRF and session messages) were not hundred page tomes. They were
concise, 2-3 page summaries. A similar effort, signed off by someone
(or someones)  I trust is all I'm asking for.

> You yourself always say how limited your
> time is and that you're working on this in your spare time. Well,
> we're in the same situation. I don't know if I can and want to invest
> a lot of time, so I can give you a detailed analysis of everything,
> especially if you only trust people you know personally, anyway.

Lets be clear here. I *didn't* say "someone I know personally". I said
"someone known to the core" -- by which I mean someone who has a long
term reputation of contributing, or of being involved in a project
that
 makes their expertise undeniable.

Example 1: I've worked very closely with Alex Gaynor, on patches large
and small. Over many years, I've come to trust his judgement. If Alex
says a patch is good, experience tells me that he's probably right.

Example 2: The most recent Django NoSQL panel contained
representatives from Mahalo, Urban Airship, Mochi Media, and Engine
Yard. These are serious companies, and you don't get a work for
serious companies unless you have serious skills. If someone from one
of these companies vouches for a patch, I have a reason to believe
that it will be good.

Of the list of names you've given of people who have contributed NoSQL
patches -- including yourself -- I recognize none of them. I don't
know where they work. They don't have a history of contribution to
Django that enables me to have confidence in their design taste and
coding skills.

That doesn't mean that their code is inherently bad -- it just means I
have no prima facie reason to trust that they know what they're
talking about.

Saying "John Smith is betting his company on Cassandra" doesn't tell
me anything. John Smith could be a particularly bad gambler, or he
could be gambling his company that currently serves 2 customers
generating 5 page requests a day.  Unless I know that John Smith has a
history of making well informed design choices, or I know that his
company is already successful, a recommendation from John Smith isn't
worth a whole lot. It's worth *something*, but by itself, it's not
enough for me to risk the reputation of the entire Django project.

> I understand your side: You don't feel qualified to
> make a decision. That's fine. But from my side it looks like I'm in
> fact wasting my time because I don't get trusted, anyway.

You appear to have some fundamental misunderstandings about how trust works.

Trust comes when you do something over and over again in a way that
enables someone else to have confidence that you're going to do it the
same way next time the same problem arises.

Trust comes 

Re: Something.is_live instead of implementation specific is_live settings

[Yo-Yo Ma]

I apologize Russell. There's been a gross understanding of what I was
asking. I'm not asking how to do "if settings.debug: x = y". I'm
asking for a way to set settings.debug to true dynamically without
having to rely on deployment specific issues. Ie, pass a variable in
when the dev server is run (by default) that allows you to set
settings.debug to true.

On Sep 24, 8:04 pm, Russell Keith-Magee 
wrote:
> On Sat, Sep 25, 2010 at 8:59 AM, Yo-Yo Ma  wrote:
> > Chuck - Thanks. Perhaps there isn't such room for improvement on the
> > topic.
>
> > Jacob - It appears to me that you don't read things before you comment
> > on them. That's two times in one post. Patience is a virtue, my
> > friend.
>
> This conversation may have started as a "lets add an 'in development'
> setting". That was very quickly refuted by two members of the
> community (one BDFL, and one person that I work with) that told you
> pretty clearly that Django best practice already has at least 2
> existing solutions that can do what you describe.
>
> The conversation has since devolved into a 'heres all the ways you
> could do it right now', and a bunch of people showing you the various
> ways that Django configurations can be used to achieve the goal you
> describe.
>
> Yes, patience is a virtue. However, in this case, your call for
> patience implies that we should have confidence that this is a
> productive, on-topic discussion that is leading to a clear design
> decision that can be implemented. I've re-read this thread, and I
> don't see any indication that this is what is happening.
>
> *You* may think that there is still a feature under discussion. The
> remainder of the people in this thread -- who, from a quick mental
> count of what experience I'm aware of, have almost 20 years of Django
> experience between them (A BDFL and core devs at 5 years each, plus a
> number of 2+ year veterans) -- are telling you that this "feature"
> isn't needed.  At which point, it's an education activity, and better
> suited to django-users.
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: 'User' object has no attribute 'backend' - issue with using auth.login()

[Yo-Yo Ma]

How can an object other than a User login with that function? The
proprietary implementation of User logins is even more of a case to
out login on User, isn't it? If you cant even login a User object
without doing special things to it first, how can you expect to login
a Foo?

On Sep 25, 4:13 am, Harro  wrote:
> Authentication = verification
> Login = saving the authenticated user so we remember them.
>
> Putting login on the user model is a bad idea.
> That will only make the whole auth app less flexible than it already
> is.
> What if I have another model which isn't a user but is able to login.
>
> Besides.. is_active does not mean you're not allowed to log in.. I'm
> currently on a website where a user can register and do things on the
> website right away and they won't be active till they have verified
> their e-mail address. So the in active user can login and start using
> the basic features right away.
>
> On Sep 24, 6:58 am, Yo-Yo Ma  wrote:
>
>
>
> > Thanks for the replies David. I didn't mean to sound brash with the
> > Joel stuff. It's just that the API didn't doesn't feel right. Perhaps
> > changing login to a method or User would fix both problems (explicit
> > better than implicit avoids confusion) because only a User logs in. A
> > User derived from authenticate() already has permission (almost) to
> > log in, so why not let them do it, and raise an exception if they try
> > when they're not .is_active?
>
> > user = authenticated('mike', 'openSesame')
> > user.login(request)
>
> > This prevents the problem from arising, without having to define a
> > __gettattr__ on User for some edge case. It also cleans up the smell.
> > I assume something like this could be changed in 1.4, no?
>
> > On Sep 23, 5:43 pm, "David P. Novakovic" 
> > wrote:
>
> > > To take something constructive from this.. perhaps backend could be a
> > > property that raises a more meaningful exception when it is called the
> > > wrong way?
>
> > > I'm not particularly for or against the idea.. but I know raising more
> > > meaningful exceptions is an issue that has received some attention
> > > previously.
>
> > > Thoughts anyone?
>
> > > On Fri, Sep 24, 2010 at 9:32 AM, David P. Novakovic
>
> > >  wrote:
> > > > Apart from being slightly offended at you posting a Joel Spolski link
> > > > to make a point, I'll address the actual issue at hand :P
>
> > > > These docs pretty clearly show authenticate happening before login.
> > > > Both in examples and the actual docs.
>
> > > >http://docs.djangoproject.com/en/dev/topics/auth/#how-to-log-a-user-in
>
> > > > Notice in particular:
>
> > > > """
> > > > Calling authenticate() first
>
> > > > When you're manually logging a user in, you must call authenticate()
> > > > before you call login(). authenticate() sets an attribute on the User
> > > > noting which authentication backend successfully authenticated that
> > > > user (see the backends documentation for details), and this
> > > > information is needed later during the login process.
> > > > """
>
> > > > The only time I could see this being a documentation issue is when
> > > > someone is implementing their own authenticate function but this
> > > > breaks the django convention if simply implementing a backend and
> > > > adding it to the list of auth backends and letting authenticate()
> > > > provide the actual authentication.
>
> > > > So yep, unfortunately this is an issue for django-users.
>
> > > > David
>
> > > > On Fri, Sep 24, 2010 at 9:02 AM, Yo-Yo Ma  
> > > > wrote:
> > > >> It is a problem with Django. I thought it was a problem with the code
> > > >> but it isn't. It's a problem with the documentation, or worse. An
> > > >> function of an API that requires running of another function to alter
> > > >> an object behind the scenes is an architectural problem that needs
> > > >> fixing. 
> > > >> Seehttp://www.joelonsoftware.com/articles/LeakyAbstractions.html
> > > >> - and furthermore, if the choice is made to leave problems like this
> > > >> unfixed, they should be documented as so. The current documentation
> > > >> here says, "It takes an HttpRequest object and a User object.". This
> > > >> isn't true, as as simple User object will not suffice. It should say,
> > > >> "It takes an HttpRequest object and a User object that has been run
> > > >> through the function authenticate() first to alter the auth backends
> > > >> that are attached as attributes to it.".
>
> > > >> This has very bad code smell, IMHO.
>
> > > >> On Sep 23, 3:47 pm, "David P. Novakovic" 
> > > >> wrote:
> > > >>> This probably should have been posted to django-users anyway.
>
> > > >>> Chances are, getting a stacktrace like this one or the last error you
> > > >>> posted are actually problems with your code and not django itself.
>
> > > >>> Unless you can show that it is actually a 

Re: four NoSQL backends you want? :)

[Florent Gallaire]

When a free software project fail to progress because of a bad
leadership, you can :

1) make a putsh.
2) make a fork.

Florent

On Sat, Sep 25, 2010 at 7:24 PM, Waldemar Kornewald
 wrote:
> On Sep 25, 4:21 pm, Russell Keith-Magee 
> wrote:
>> My reason for wanting this is that I'm simply not an expert in any of
>> these backends. I know SQL quite well, but I haven't had occasion to
>> try out other backends in depth. I can judge the technical merits of a
>> patch based on what I know, but I don't want to make a judgement based
>> on incompletely knowledge. I need to rely on those that I know and
>> trust to give me confidence that nothing has been missed.
>
> This is really the biggest problem. If you work in a company where
> your lead developer or manager doesn't know enough about the
> technology and for that reason wants to have a huge amount of analysis
> and review how are you going to get anything done? You'd surely call
> such a company dysfunctional. You yourself always say how limited your
> time is and that you're working on this in your spare time. Well,
> we're in the same situation. I don't know if I can and want to invest
> a lot of time, so I can give you a detailed analysis of everything,
> especially if you only trust people you know personally, anyway. I
> mean, try convincing someone who doesn't know SQL that Django's ORM
> supports JOINs and aggregates and UPDATE operations. It's practically
> impossible. That's exactly how I feel. We've got a lot of users with
> experience in their particular NoSQL DBs and some of them are even
> betting their business on those backends and use them for commercial
> projects without any problems and even that doesn't seem to be
> convincing enough. I understand your side: You don't feel qualified to
> make a decision. That's fine. But from my side it looks like I'm in
> fact wasting my time because I don't get trusted, anyway. So, is
> anyone in the Django core team experienced enough with NoSQL DBs to
> make a qualified analysis and is that person serious about helping to
> get NoSQL support into Django 1.4? Without such a person helping us it
> doesn't make sense to continue this project.
>
> If you want to know whether users face surprises with Django-nonrel
> please read this post from yesterday, for example:
> http://groups.google.com/group/google-appengine-python/msg/2ee52c2aa8ab720b
>
>> Lastly, we need to resolve the AutoField problem. This is the biggest
>> outstanding technical issue. I can't say I've got any particularly
>> brilliant ideas on how to solve it. Suggestions are welcome.
>
> Wasn't your original suggestion good enough? We could detect whether
> the user only has SQL backends and activate the old validation
> behavior, but show a deprecation warning whenever things are expected
> to change. If the user has a NoSQL backend the new validation behavior
> is automatically activated. A few releases later we can get rid of the
> old behavior.
>
>> As for timing: I'm on record saying a number of times now that this
>> isn't something I'm targeting for 1.3. We need to have a release that
>> is low on features and high on bugfixes. Given the time required to
>> make large scale database backend changes, I simply don't have enough
>> bandwidth to satisfy the community needs for 1.3 *and* the needs of
>> query-refactor. However, if people like yourself that are motivated in
>> this are can get the pieces in place during the 1.3 development cycle,
>> query-refactor could be an early delivery in the 1.4 timeframe (i.e.,
>> early next year).
>
> That's fine.
>
> Bye,
> Waldemar
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: proposal for lazy foreignkeys

[flo...@gmail.com]

On Sep 25, 10:47 am, Carl Meyer  wrote:
> The concept:
>
> We introduce the "virtual" model, which is an abstract model with the
> following additional characteristics:

I'm a fan of this implementation strategy, it's a much better solution
than the setting approach IMO.

Thanks,
Eric Florenzano

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: proposal for lazy foreignkeys

[Carl Meyer]

On Sep 25, 1:50 pm, Alex Gaynor  wrote:
> ISTM this would solve the "auth.User" issue, but doesn't help reusable
> apps at large: one can trivially imagine a project that wants voting
> (or tagging ;), or commenting, or ...) on more than one model.

Of course! This isn't a silver bullet for every single use case. For
reusable apps that need to support attachment to multiple models,
either a GFK would still be used, or even better, some solution for
multiple-instances-of-an-app (I believe the app-cache-refactor this
GSoC moved us somewhat closer to this possibility, but doesn't
actually support it yet).

But I do think there's a substantial class of reusable apps currently
using GFKs where a lazy foreignkey would serve better. For instance,
if this proposal went through, I'd personally author a reusable voting
app that only supports voting on one domain model, but gives you
efficient and less-hassle no-GFK database schema in exchange. I think
a lot of projects would find that useful, and for now I could simply
point people who want voting-on-multiple-models to alternative apps
using GFKs.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: proposal for lazy foreignkeys

[Alex Gaynor]

On Sat, Sep 25, 2010 at 1:47 PM, Carl Meyer  wrote:
> Hi all,
>
> I've seen some level of interest in the idea of a lazy foreign key
> (one whose target table is determined by project configuration in some
> way, not hardcoded by the app/model in which it lives). The idea was
> most recently brought up again in Eric Florenzano's keynote at
> DjangoCon. I have some ideas regarding possible API for this, and
> would be glad for feedback.
>
> First, a couple motivating use cases:
>
> 1. Reusable apps overuse GenericForeignKey. GFKs are inefficient and
> smell bad. They're good to have around when you really need to link to
> any one of a possibly-growing set of models. But currently reusable
> apps often use them anytime they want to link to "some domain model
> but we don't know which one" - even if in practice in most cases it
> will be only one! A lazy foreign key would be a better solution.
>
> 2. Standardization with flexibility: i.e. possible-future replacement
> of contrib.auth.User. To be clear, I am not at this point proposing
> any changes at all to contrib.auth. But in some future possible
> contrib.auth refactoring, a lazy foreign key could provide a way for
> reusable apps to point to a common User model, without Django having
> to provide a concrete implementation of that model.
>
> The concept:
>
> We introduce the "virtual" model, which is an abstract model with the
> following additional characteristics:
>
> - It can be the target of a ForeignKey.
> - It may only have one direct concrete subclass, and if it is the
> target of any ForeignKey it must have exactly one.
>
> At runtime, any ForeignKeys pointing to a virtual model are resolved
> to actually point to the concrete subclass of that virtual model.
>
> Like an abstract model, a virtual model may include fields, methods,
> etc. These can be considered the specification of an interface: any
> model with a ForeignKey to this virtual model can expect the concrete
> model to satisfy that interface. This is particularly helpful for a
> contrib.auth-type use case: reusable apps don't only need a User model
> to point FKs at, they also often need at least some minimal set of
> fields/properties they can rely on being present.
>
> It's not required for the virtual model to have any fields, of course:
> in some use cases (voting, tagging) the reusable app doesn't need to
> know anything at all about its target model. A hypothetical voting app
> could simply provide an empty "VotableObject" virtual model, which
> would be inherited by the domain model which can receive votes. Since
> Django already supports multiple inheritance for abstract models, this
> is a minimal and non-restrictive requirement for the domain model
> author.
>
> Advantages of this proposal:
>
> 1. No new settings.
> 2. In terms of new code API, almost nothing: a new "virtual = True"
> Meta keyword.
> 3. Very little conceptual overhead; reuses existing constructs as much
> as possible.
>
> I plan to put together a patch to show working code for this, but I'd
> be glad for any feedback at this point, especially if there are
> obvious conceptual problems I'm overlooking. Thanks!
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

ISTM this would solve the "auth.User" issue, but doesn't help reusable
apps at large: one can trivially imagine a project that wants voting
(or tagging ;), or commenting, or ...) on more than one model.

In any event, my brain needs to digest (and I need lunch),
Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

proposal for lazy foreignkeys

[Carl Meyer]

Hi all,

I've seen some level of interest in the idea of a lazy foreign key
(one whose target table is determined by project configuration in some
way, not hardcoded by the app/model in which it lives). The idea was
most recently brought up again in Eric Florenzano's keynote at
DjangoCon. I have some ideas regarding possible API for this, and
would be glad for feedback.

First, a couple motivating use cases:

1. Reusable apps overuse GenericForeignKey. GFKs are inefficient and
smell bad. They're good to have around when you really need to link to
any one of a possibly-growing set of models. But currently reusable
apps often use them anytime they want to link to "some domain model
but we don't know which one" - even if in practice in most cases it
will be only one! A lazy foreign key would be a better solution.

2. Standardization with flexibility: i.e. possible-future replacement
of contrib.auth.User. To be clear, I am not at this point proposing
any changes at all to contrib.auth. But in some future possible
contrib.auth refactoring, a lazy foreign key could provide a way for
reusable apps to point to a common User model, without Django having
to provide a concrete implementation of that model.

The concept:

We introduce the "virtual" model, which is an abstract model with the
following additional characteristics:

- It can be the target of a ForeignKey.
- It may only have one direct concrete subclass, and if it is the
target of any ForeignKey it must have exactly one.

At runtime, any ForeignKeys pointing to a virtual model are resolved
to actually point to the concrete subclass of that virtual model.

Like an abstract model, a virtual model may include fields, methods,
etc. These can be considered the specification of an interface: any
model with a ForeignKey to this virtual model can expect the concrete
model to satisfy that interface. This is particularly helpful for a
contrib.auth-type use case: reusable apps don't only need a User model
to point FKs at, they also often need at least some minimal set of
fields/properties they can rely on being present.

It's not required for the virtual model to have any fields, of course:
in some use cases (voting, tagging) the reusable app doesn't need to
know anything at all about its target model. A hypothetical voting app
could simply provide an empty "VotableObject" virtual model, which
would be inherited by the domain model which can receive votes. Since
Django already supports multiple inheritance for abstract models, this
is a minimal and non-restrictive requirement for the domain model
author.

Advantages of this proposal:

1. No new settings.
2. In terms of new code API, almost nothing: a new "virtual = True"
Meta keyword.
3. Very little conceptual overhead; reuses existing constructs as much
as possible.

I plan to put together a patch to show working code for this, but I'd
be glad for any feedback at this point, especially if there are
obvious conceptual problems I'm overlooking. Thanks!

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: four NoSQL backends you want? :)

[Waldemar Kornewald]

On Sep 25, 4:21 pm, Russell Keith-Magee 
wrote:
> My reason for wanting this is that I'm simply not an expert in any of
> these backends. I know SQL quite well, but I haven't had occasion to
> try out other backends in depth. I can judge the technical merits of a
> patch based on what I know, but I don't want to make a judgement based
> on incompletely knowledge. I need to rely on those that I know and
> trust to give me confidence that nothing has been missed.

This is really the biggest problem. If you work in a company where
your lead developer or manager doesn't know enough about the
technology and for that reason wants to have a huge amount of analysis
and review how are you going to get anything done? You'd surely call
such a company dysfunctional. You yourself always say how limited your
time is and that you're working on this in your spare time. Well,
we're in the same situation. I don't know if I can and want to invest
a lot of time, so I can give you a detailed analysis of everything,
especially if you only trust people you know personally, anyway. I
mean, try convincing someone who doesn't know SQL that Django's ORM
supports JOINs and aggregates and UPDATE operations. It's practically
impossible. That's exactly how I feel. We've got a lot of users with
experience in their particular NoSQL DBs and some of them are even
betting their business on those backends and use them for commercial
projects without any problems and even that doesn't seem to be
convincing enough. I understand your side: You don't feel qualified to
make a decision. That's fine. But from my side it looks like I'm in
fact wasting my time because I don't get trusted, anyway. So, is
anyone in the Django core team experienced enough with NoSQL DBs to
make a qualified analysis and is that person serious about helping to
get NoSQL support into Django 1.4? Without such a person helping us it
doesn't make sense to continue this project.

If you want to know whether users face surprises with Django-nonrel
please read this post from yesterday, for example:
http://groups.google.com/group/google-appengine-python/msg/2ee52c2aa8ab720b

> Lastly, we need to resolve the AutoField problem. This is the biggest
> outstanding technical issue. I can't say I've got any particularly
> brilliant ideas on how to solve it. Suggestions are welcome.

Wasn't your original suggestion good enough? We could detect whether
the user only has SQL backends and activate the old validation
behavior, but show a deprecation warning whenever things are expected
to change. If the user has a NoSQL backend the new validation behavior
is automatically activated. A few releases later we can get rid of the
old behavior.

> As for timing: I'm on record saying a number of times now that this
> isn't something I'm targeting for 1.3. We need to have a release that
> is low on features and high on bugfixes. Given the time required to
> make large scale database backend changes, I simply don't have enough
> bandwidth to satisfy the community needs for 1.3 *and* the needs of
> query-refactor. However, if people like yourself that are motivated in
> this are can get the pieces in place during the 1.3 development cycle,
> query-refactor could be an early delivery in the 1.4 timeframe (i.e.,
> early next year).

That's fine.

Bye,
Waldemar

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: four NoSQL backends you want? :)

[Russell Keith-Magee]

On Sat, Sep 25, 2010 at 8:47 PM, Waldemar Kornewald
 wrote:
> Hi,
> in my last discussion on django-users Russell told me that he'd like
> to see four proof-of-concept (or better) backends before considering
> NoSQL for inclusion in trunk.

The number 4 wasn't actually the important bit - it was that I want to
see a range of noSQL approaches represented. I don't want to see 4
key-value stores; I want to see a key-value store, and a document
store, and a column store, etc. I need to see that the API is rich
enough to cover all noSQL bases.

> The primary point was that enough
> eyeballs have looked at the API, first. Now we finally have four
> backends for Django-nonrel:
>
> App Engine (used in production), developed by Thomas Wanschik and me
> http://www.allbuttonspressed.com/projects/djangoappengine
>
> MongoDB (used in production), developed by Flavio Percoco Premoli,
> Alberto Paro, George Karpenkov, and me
> http://github.com/FlaPer87/django-mongodb-engine
>
> Cassandra (alpha/experimental), developed by Rob Vaterlaus with very
> minor hints from me
> http://github.com/vaterlaus/django_cassandra_backend
>
> ElasticSearch (alpha/experimental), developed by Alberto Paro
> http://github.com/aparo/django-elasticsearch
>
> All of them are based on our nonrel backend API (djangotoolbox.db). It
> should be relatively easy to extend the API to support both
> Django-nonrel and Alex' query-refactor branch at the same time. The
> backends will probably only need minor changes, if at all.
>
> Russell and the rest of the Django core team, if we make those four
> backends, developed with 12 eyeballs ;) work on the query-refactor
> branch, what else is necessary to get NoSQL support into trunk? Please
> don't tell me that you also want a CouchDB backend. :(
>
> My only requirement before porting the backends is that the
> (Native)AutoField issue gets resolved, first. That will simplify our
> porting effort and allow us to reuse our existing unit tests and
> project code.

Firstly, I need to see these backends actually implemented on query-refactor.

Secondly, I need to have a better understanding of what is meant when
you say "alpha/experimental" or "in production" support for a backend.
I have no doubt that you can get any backend working for simple cases.
I have no doubt that those simple cases may well be sufficient for
certain production purposes.

It's the complex cases that have me concerned. I need to know that a
user of  won't be overwhelmingly surprised if
they try to use Django to access their data store. What data store
features features are and aren't supported? When a feature isn't
supported, is this due to conceptual problems mapping the store onto
the ORM, technical limitations of the store itself, or technical
limitations imposed by the query-refactor branch? When a feature *is*
supported, is it supported in a way that makes conceptual sense?

To counter this, I would like to see a comprehensive summary of the
state of play of the level of support for each storage backend. This
includes:
 * How the ORM maps to the backend
 * Capabilities that are lost as a result of this mapping
 * Capabilities that have been implemented, and how
 * Capabilities that can't/haven't be implemented (and why)

Features like CSRF and session messages maintained wiki pages with
this sort of problem analysis prior to their merge to trunk. This
serves as excellent design documentation describing why the feature is
the way it is. I'd like to see an analogous page for query-refactor.

Thirdly, I'd like to see some independent verification of the claims
being made. It's fine to have the person who wrote a particular
backend saying "feature XYZ is complete", but I'd like to see
independent verification of this fact -- preferably from someone known
to the core team, not just a random stranger. The panelists at the
DjangoCon 2010 NoSQL panel would be a good starting place to look for
this sort of verification, but they're certainly not the only
candidates.

My reason for wanting this is that I'm simply not an expert in any of
these backends. I know SQL quite well, but I haven't had occasion to
try out other backends in depth. I can judge the technical merits of a
patch based on what I know, but I don't want to make a judgement based
on incompletely knowledge. I need to rely on those that I know and
trust to give me confidence that nothing has been missed.

Lastly, we need to resolve the AutoField problem. This is the biggest
outstanding technical issue. I can't say I've got any particularly
brilliant ideas on how to solve it. Suggestions are welcome.

As for timing: I'm on record saying a number of times now that this
isn't something I'm targeting for 1.3. We need to have a release that
is low on features and high on bugfixes. Given the time required to
make large scale database backend changes, I simply don't have enough
bandwidth to satisfy the community needs for 1.3 *and* the needs of
query-refactor. 

four NoSQL backends you want? :)

[Waldemar Kornewald]

Hi,
in my last discussion on django-users Russell told me that he'd like
to see four proof-of-concept (or better) backends before considering
NoSQL for inclusion in trunk. The primary point was that enough
eyeballs have looked at the API, first. Now we finally have four
backends for Django-nonrel:

App Engine (used in production), developed by Thomas Wanschik and me
http://www.allbuttonspressed.com/projects/djangoappengine

MongoDB (used in production), developed by Flavio Percoco Premoli,
Alberto Paro, George Karpenkov, and me
http://github.com/FlaPer87/django-mongodb-engine

Cassandra (alpha/experimental), developed by Rob Vaterlaus with very
minor hints from me
http://github.com/vaterlaus/django_cassandra_backend

ElasticSearch (alpha/experimental), developed by Alberto Paro
http://github.com/aparo/django-elasticsearch

All of them are based on our nonrel backend API (djangotoolbox.db). It
should be relatively easy to extend the API to support both
Django-nonrel and Alex' query-refactor branch at the same time. The
backends will probably only need minor changes, if at all.

Russell and the rest of the Django core team, if we make those four
backends, developed with 12 eyeballs ;) work on the query-refactor
branch, what else is necessary to get NoSQL support into trunk? Please
don't tell me that you also want a CouchDB backend. :(

My only requirement before porting the backends is that the
(Native)AutoField issue gets resolved, first. That will simplify our
porting effort and allow us to reuse our existing unit tests and
project code.

Bye,
Waldemar Kornewald

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: #12012 Logging: request for comments

[Jannis Leidel]

On 25.09.2010, at 08:16, Russell Keith-Magee wrote:

> Hi all,
> 
> I've just uploaded a first draft at a patch introducing logging into
> Django [1]. I'm calling for feedback on this patch.
> 
> [1] http://code.djangoproject.com/attachment/ticket/12012/t12012-alpha1.diff
> 
> This patch is heavily drawn from the work that Vinay Sajip has done in
> this area, but it also includes some significant changes to his most
> recent patches.
> 
> The patch introduces two settings:
> 
> LOGGING_CONFIG - a callable that should be used to configure the
> logging machinery
> LOGGING - the configuration data to pass to the configuration function.
> 
> By default, LOGGING_CONFIG points to logging.config.dictConfig, which
> means that LOGGING should be a dict-style logging configuration (as
> introduce by Python 2.7). A copy of dictConfig is included in utils
> for backwards compatibility. However, by changing LOGGING_CONFIG, you
> could use any configuration scheme you like.
> 
> In addition, a new convention is introduced. If a Django app includes
> a 'startup.py' as a sibling module to models.py, tests.py etc, then
> this module will be loaded *exactly once* during the startup of the
> app. It will be loaded *after* the settings have been initialized, but
> *before* models.py has been imported.
> 
> The patch includes the changes to the new project settings.py to show
> what LOGGING would look like in practice. This logging configuration
> puts everything to console, except for errors in the request process,
> which are mailed to the admin. This means redirecting 500 errors to
> something other than your email box is now a 1 line configuration
> item.
> 
> The patch also includes logging entries for everywhere in the code
> where a 4XX or 5XX error is raised. 4XX's are raised as warnings;
> 5XX's as errors.
> 
> Lastly, there is a separate logger that logs, at the debug level,
> every SQL statement that is executed. If you add a handler for
> django.db.backends that catches the DEBUG level, you will get this
> output.
> 
> There are no docs because I'm waiting for the design to be finalized
> before I start writing; there are no tests because this is something
> that is a little difficult to test.
> 
> At this point, I'm calling for feedback, particularly on the following:
> 
> * logging config as the last stage of settings loading. Is this the
> right place? Can anyone think of a better place?
> 
> * The default logging configuration. Have I got the
> propagate/override options right for sensible defaults (both in global
> and new-project settings)?
> 
> * The logging calls that have been introduced. Is this too much or
> too little? I'd rather err on the side of caution here (we can always
> add extra logging later), but I'd like suggestions on anything else
> people think should be logged. Also, are they logged at the right
> level (e.g., is a 404 a warning?).
> 
> * The startup.py convention (and implementation). Is this necessary?
> Does it address (or not address) any other prominent "on startup" use
> cases? There's also a crossover here with Arthur's GSoC work; is the
> startup code sufficiently important that we need it anyway, or can we
> defer until the app refactor lands?

To expand on this a bit, the refactored app cache from Arthur's GSoC branch 
introduces a dedicated place for app related information to live in, the app 
class. With the dotted app path given to a new setting called APP_CLASSES it 
will be picked up during startup by the app cache, creating app instances.

Given the fact that the current implementation of the app cache does quite a 
few hoops to make it possible to implicitely import the models modules by 
iterating over INSTALLED_APPS, I'd like to propose to rather move the logging 
initialization to the app class initialization, instead of introducing another 
place of implicite importing -- to prevent having ambiguous locations for app 
specific code execution.

Only problem is that the inclusion of the refactored app cache into trunk 
wasn't planned for 1.3, which is why I suggest we recommend using the 
management.py for optional logging initialization in 1.3 and add app-level 
logging hooks in 1.4 when the new app cache lands.

Jannis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: 'User' object has no attribute 'backend' - issue with using auth.login()

[Harro]

Authentication = verification
Login = saving the authenticated user so we remember them.

Putting login on the user model is a bad idea.
That will only make the whole auth app less flexible than it already
is.
What if I have another model which isn't a user but is able to login.

Besides.. is_active does not mean you're not allowed to log in.. I'm
currently on a website where a user can register and do things on the
website right away and they won't be active till they have verified
their e-mail address. So the in active user can login and start using
the basic features right away.



On Sep 24, 6:58 am, Yo-Yo Ma  wrote:
> Thanks for the replies David. I didn't mean to sound brash with the
> Joel stuff. It's just that the API didn't doesn't feel right. Perhaps
> changing login to a method or User would fix both problems (explicit
> better than implicit avoids confusion) because only a User logs in. A
> User derived from authenticate() already has permission (almost) to
> log in, so why not let them do it, and raise an exception if they try
> when they're not .is_active?
>
> user = authenticated('mike', 'openSesame')
> user.login(request)
>
> This prevents the problem from arising, without having to define a
> __gettattr__ on User for some edge case. It also cleans up the smell.
> I assume something like this could be changed in 1.4, no?
>
> On Sep 23, 5:43 pm, "David P. Novakovic" 
> wrote:
>
>
>
> > To take something constructive from this.. perhaps backend could be a
> > property that raises a more meaningful exception when it is called the
> > wrong way?
>
> > I'm not particularly for or against the idea.. but I know raising more
> > meaningful exceptions is an issue that has received some attention
> > previously.
>
> > Thoughts anyone?
>
> > On Fri, Sep 24, 2010 at 9:32 AM, David P. Novakovic
>
> >  wrote:
> > > Apart from being slightly offended at you posting a Joel Spolski link
> > > to make a point, I'll address the actual issue at hand :P
>
> > > These docs pretty clearly show authenticate happening before login.
> > > Both in examples and the actual docs.
>
> > >http://docs.djangoproject.com/en/dev/topics/auth/#how-to-log-a-user-in
>
> > > Notice in particular:
>
> > > """
> > > Calling authenticate() first
>
> > > When you're manually logging a user in, you must call authenticate()
> > > before you call login(). authenticate() sets an attribute on the User
> > > noting which authentication backend successfully authenticated that
> > > user (see the backends documentation for details), and this
> > > information is needed later during the login process.
> > > """
>
> > > The only time I could see this being a documentation issue is when
> > > someone is implementing their own authenticate function but this
> > > breaks the django convention if simply implementing a backend and
> > > adding it to the list of auth backends and letting authenticate()
> > > provide the actual authentication.
>
> > > So yep, unfortunately this is an issue for django-users.
>
> > > David
>
> > > On Fri, Sep 24, 2010 at 9:02 AM, Yo-Yo Ma  
> > > wrote:
> > >> It is a problem with Django. I thought it was a problem with the code
> > >> but it isn't. It's a problem with the documentation, or worse. An
> > >> function of an API that requires running of another function to alter
> > >> an object behind the scenes is an architectural problem that needs
> > >> fixing. Seehttp://www.joelonsoftware.com/articles/LeakyAbstractions.html
> > >> - and furthermore, if the choice is made to leave problems like this
> > >> unfixed, they should be documented as so. The current documentation
> > >> here says, "It takes an HttpRequest object and a User object.". This
> > >> isn't true, as as simple User object will not suffice. It should say,
> > >> "It takes an HttpRequest object and a User object that has been run
> > >> through the function authenticate() first to alter the auth backends
> > >> that are attached as attributes to it.".
>
> > >> This has very bad code smell, IMHO.
>
> > >> On Sep 23, 3:47 pm, "David P. Novakovic" 
> > >> wrote:
> > >>> This probably should have been posted to django-users anyway.
>
> > >>> Chances are, getting a stacktrace like this one or the last error you
> > >>> posted are actually problems with your code and not django itself.
>
> > >>> Unless you can show that it is actually a problem with django and not
> > >>> the way you are using it, it'd be better addressed on django-users
> > >>> first.
>
> > >>> David
>
> > >>> On Fri, Sep 24, 2010 at 5:41 AM, Jacob Kaplan-Moss  
> > >>> wrote:
> > >>> > On Thu, Sep 23, 2010 at 2:18 PM, Yo-Yo Ma  
> > >>> > wrote:
> > >>> >> Hey Jacob, understood. Here's some more details that might help:
> > >>> > [snip]
> > >>> >>                if user.check_password(request.POST.get('password',
> 

Re: #12012 Logging: request for comments

[Antoni Aloy]

Hello,

Actually what I'm used to do in my application is to have a logging
configuration in the settings.py livel and

import logging
logging.getLogger(__name__)

at the module level, so each module gets its own logger. In the
settings level and via a local_settings file one can seat each logging
level. Adding a startup.py at the application level could save me some
lines of code so I'm +1 on it :). For me it's also a a good idea as
removes some decisions about "where I have to put that code that needs
to be loaded once".

In a logging system I think is important to differentiate between
logging in development where we neeed a console log and logging in
production where we need a file log as a minimum, and I don't see how
can be easily managed unless the Django logging module has additional
configuration to add the default logging output.

The Django logging module should also show how "the standard way" to
create loggers for the Django applications, and I don't see an easy
way to do it. Perhaps it's just a matter of documenting it, I don't
know.

So I'd like to add  2 main doubts to the thread

1. How the logging process could be standardized for all Django apps?
2. How can we change the logging setting from
development/preproducction to a production configuration just changing
some sort of local_setting?

We could do some profile tests to see if

http://docs.python.org/library/logging.html?highlight=logging#logging.Logger.isEnabledFor

it's worth to be added in the code.

One last doubt, perhaps offtopic I have read logging module is slow,
good enough for 90% of applications but for the rest. Actually is
enough for me, but I can't see  to deal with log on big systems

Regards,

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: #12012 Logging: request for comments

[Russell Keith-Magee]

Hi David,

I'm not sure I completely follow - what exactly are you looking to
have logged? The pattern that was matched by the request?

As for raising a ticket - don't worry. About that at this point. For
the moment, just keep he discussion on the ticket; if we decide that
this is needed, we'll roll it into the commit for the main ticket. If
you have a patch, just stick it on #12012.

Yours,
Russ Magee %-)

On Saturday, September 25, 2010, David P. Novakovic
 wrote:
> Hey mate,
>
> Great stuff! A cursory glance shows there isn't anything to log debug
> output from url resolution.. something I think I need to add.. I'll
> busy a ticket for it :)
>
> D
>
> On Sat, Sep 25, 2010 at 4:16 PM, Russell Keith-Magee
>  wrote:
>> Hi all,
>>
>> I've just uploaded a first draft at a patch introducing logging into
>> Django [1]. I'm calling for feedback on this patch.
>>
>> [1] http://code.djangoproject.com/attachment/ticket/12012/t12012-alpha1.diff
>>
>> This patch is heavily drawn from the work that Vinay Sajip has done in
>> this area, but it also includes some significant changes to his most
>> recent patches.
>>
>> The patch introduces two settings:
>>
>> LOGGING_CONFIG - a callable that should be used to configure the
>> logging machinery
>> LOGGING - the configuration data to pass to the configuration function.
>>
>> By default, LOGGING_CONFIG points to logging.config.dictConfig, which
>> means that LOGGING should be a dict-style logging configuration (as
>> introduce by Python 2.7). A copy of dictConfig is included in utils
>> for backwards compatibility. However, by changing LOGGING_CONFIG, you
>> could use any configuration scheme you like.
>>
>> In addition, a new convention is introduced. If a Django app includes
>> a 'startup.py' as a sibling module to models.py, tests.py etc, then
>> this module will be loaded *exactly once* during the startup of the
>> app. It will be loaded *after* the settings have been initialized, but
>> *before* models.py has been imported.
>>
>> The patch includes the changes to the new project settings.py to show
>> what LOGGING would look like in practice. This logging configuration
>> puts everything to console, except for errors in the request process,
>> which are mailed to the admin. This means redirecting 500 errors to
>> something other than your email box is now a 1 line configuration
>> item.
>>
>> The patch also includes logging entries for everywhere in the code
>> where a 4XX or 5XX error is raised. 4XX's are raised as warnings;
>> 5XX's as errors.
>>
>> Lastly, there is a separate logger that logs, at the debug level,
>> every SQL statement that is executed. If you add a handler for
>> django.db.backends that catches the DEBUG level, you will get this
>> output.
>>
>> There are no docs because I'm waiting for the design to be finalized
>> before I start writing; there are no tests because this is something
>> that is a little difficult to test.
>>
>> At this point, I'm calling for feedback, particularly on the following:
>>
>>  * logging config as the last stage of settings loading. Is this the
>> right place? Can anyone think of a better place?
>>
>>  * The default logging configuration. Have I got the
>> propagate/override options right for sensible defaults (both in global
>> and new-project settings)?
>>
>>  * The logging calls that have been introduced. Is this too much or
>> too little? I'd rather err on the side of caution here (we can always
>> add extra logging later), but I'd like suggestions on anything else
>> people think should be logged. Also, are they logged at the right
>> level (e.g., is a 404 a warning?).
>>
>>  * The startup.py convention (and implementation). Is this necessary?
>> Does it address (or not address) any other prominent "on startup" use
>> cases? There's also a crossover here with Arthur's GSoC work; is the
>> startup code sufficiently important that we need it anyway, or can we
>> defer until the app refactor lands?
>>
>> So - have at it. I'm really excited by this; so let me know everywhere
>> I've messed up so that we can get this into trunk.
>>
>> Russ %-)
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-develop...@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.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are 

Re: #12012 Logging: request for comments

[David P. Novakovic]

Hey mate,

Great stuff! A cursory glance shows there isn't anything to log debug
output from url resolution.. something I think I need to add.. I'll
busy a ticket for it :)

D

On Sat, Sep 25, 2010 at 4:16 PM, Russell Keith-Magee
 wrote:
> Hi all,
>
> I've just uploaded a first draft at a patch introducing logging into
> Django [1]. I'm calling for feedback on this patch.
>
> [1] http://code.djangoproject.com/attachment/ticket/12012/t12012-alpha1.diff
>
> This patch is heavily drawn from the work that Vinay Sajip has done in
> this area, but it also includes some significant changes to his most
> recent patches.
>
> The patch introduces two settings:
>
> LOGGING_CONFIG - a callable that should be used to configure the
> logging machinery
> LOGGING - the configuration data to pass to the configuration function.
>
> By default, LOGGING_CONFIG points to logging.config.dictConfig, which
> means that LOGGING should be a dict-style logging configuration (as
> introduce by Python 2.7). A copy of dictConfig is included in utils
> for backwards compatibility. However, by changing LOGGING_CONFIG, you
> could use any configuration scheme you like.
>
> In addition, a new convention is introduced. If a Django app includes
> a 'startup.py' as a sibling module to models.py, tests.py etc, then
> this module will be loaded *exactly once* during the startup of the
> app. It will be loaded *after* the settings have been initialized, but
> *before* models.py has been imported.
>
> The patch includes the changes to the new project settings.py to show
> what LOGGING would look like in practice. This logging configuration
> puts everything to console, except for errors in the request process,
> which are mailed to the admin. This means redirecting 500 errors to
> something other than your email box is now a 1 line configuration
> item.
>
> The patch also includes logging entries for everywhere in the code
> where a 4XX or 5XX error is raised. 4XX's are raised as warnings;
> 5XX's as errors.
>
> Lastly, there is a separate logger that logs, at the debug level,
> every SQL statement that is executed. If you add a handler for
> django.db.backends that catches the DEBUG level, you will get this
> output.
>
> There are no docs because I'm waiting for the design to be finalized
> before I start writing; there are no tests because this is something
> that is a little difficult to test.
>
> At this point, I'm calling for feedback, particularly on the following:
>
>  * logging config as the last stage of settings loading. Is this the
> right place? Can anyone think of a better place?
>
>  * The default logging configuration. Have I got the
> propagate/override options right for sensible defaults (both in global
> and new-project settings)?
>
>  * The logging calls that have been introduced. Is this too much or
> too little? I'd rather err on the side of caution here (we can always
> add extra logging later), but I'd like suggestions on anything else
> people think should be logged. Also, are they logged at the right
> level (e.g., is a 404 a warning?).
>
>  * The startup.py convention (and implementation). Is this necessary?
> Does it address (or not address) any other prominent "on startup" use
> cases? There's also a crossover here with Arthur's GSoC work; is the
> startup code sufficiently important that we need it anyway, or can we
> defer until the app refactor lands?
>
> So - have at it. I'm really excited by this; so let me know everywhere
> I've messed up so that we can get this into trunk.
>
> Russ %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

#12012 Logging: request for comments

[Russell Keith-Magee]

Hi all,

I've just uploaded a first draft at a patch introducing logging into
Django [1]. I'm calling for feedback on this patch.

[1] http://code.djangoproject.com/attachment/ticket/12012/t12012-alpha1.diff

This patch is heavily drawn from the work that Vinay Sajip has done in
this area, but it also includes some significant changes to his most
recent patches.

The patch introduces two settings:

LOGGING_CONFIG - a callable that should be used to configure the
logging machinery
LOGGING - the configuration data to pass to the configuration function.

By default, LOGGING_CONFIG points to logging.config.dictConfig, which
means that LOGGING should be a dict-style logging configuration (as
introduce by Python 2.7). A copy of dictConfig is included in utils
for backwards compatibility. However, by changing LOGGING_CONFIG, you
could use any configuration scheme you like.

In addition, a new convention is introduced. If a Django app includes
a 'startup.py' as a sibling module to models.py, tests.py etc, then
this module will be loaded *exactly once* during the startup of the
app. It will be loaded *after* the settings have been initialized, but
*before* models.py has been imported.

The patch includes the changes to the new project settings.py to show
what LOGGING would look like in practice. This logging configuration
puts everything to console, except for errors in the request process,
which are mailed to the admin. This means redirecting 500 errors to
something other than your email box is now a 1 line configuration
item.

The patch also includes logging entries for everywhere in the code
where a 4XX or 5XX error is raised. 4XX's are raised as warnings;
5XX's as errors.

Lastly, there is a separate logger that logs, at the debug level,
every SQL statement that is executed. If you add a handler for
django.db.backends that catches the DEBUG level, you will get this
output.

There are no docs because I'm waiting for the design to be finalized
before I start writing; there are no tests because this is something
that is a little difficult to test.

At this point, I'm calling for feedback, particularly on the following:

 * logging config as the last stage of settings loading. Is this the
right place? Can anyone think of a better place?

 * The default logging configuration. Have I got the
propagate/override options right for sensible defaults (both in global
and new-project settings)?

 * The logging calls that have been introduced. Is this too much or
too little? I'd rather err on the side of caution here (we can always
add extra logging later), but I'd like suggestions on anything else
people think should be logged. Also, are they logged at the right
level (e.g., is a 404 a warning?).

 * The startup.py convention (and implementation). Is this necessary?
Does it address (or not address) any other prominent "on startup" use
cases? There's also a crossover here with Arthur's GSoC work; is the
startup code sufficiently important that we need it anyway, or can we
defer until the app refactor lands?

So - have at it. I'm really excited by this; so let me know everywhere
I've messed up so that we can get this into trunk.

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.