Re: proposal for lazy foreignkeys
On Sun, Sep 26, 2010 at 1:47 AM, 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! On first inspection, absent of an implementation, I think this is an interesting approach. My biggest technical concern is the same as Alex's -- that it doesn't address the 'FK to multiple models' problem. While I agree with your 'no silver bullet' response to Alex, I also don't want to end up with two (or more) completely different ways of solving the same problem. At the very least, I'd like to have some certainty that the solution for single concrete class problem will be conceptually similar to the multiple concrete class problem. I also have two technical concerns about how the virtual keyword will work in practice. Firstly, take the likely migration path for contrib.auth. We would introduce an AbstractUser that encompasses the 'basic' concept of a user, and is marked as a virtual. But we still need to ship a concrete User that provides the current implementation. At which point, we now have our single allowed concrete instantiation, and users can't define their own User class. I can see this being a common pattern; if you want your app to work out of the box, you will provide a bare-bones concrete implementation, which will then block anyone else from providing a concrete implementation. This necessitates introducing either the ability to hide a model, or provide a different way of registering models so that unneeded concrete types aren't instantiated. Of course, the simple solution here would be to split the concrete model out into a different app, so that you optionally include auth.User if you actually want it. Secondly, this approach requires that content objects that are to be the target of these relationships must share a virtual base class. This makes for great pure-OO, but it sucks from the point of view of duck typing. For example, consider the case of tagging -- if you want to put
Re: four NoSQL backends you want? :)
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 by reciprocating -- by helping someone do someth
Re: Something.is_live instead of implementation specific is_live settings
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()
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 problem with django and not > > > >>> the way you are using it, it'd be better addressed on django-users > > > >>> first. > > > > >>> David > > > > >>> O
Re: four NoSQL backends you want? :)
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
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
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
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
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? :)
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? :)
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. However, if people like you
four NoSQL backends you want? :)
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
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()
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', > > >>> >> '')): > > >>> >> login(request, user) > > > >>> > As Santiago mentioned, you need to call authenticate() before calling > > >>> > login(). > > >>>
Re: #12012 Logging: request for comments
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
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 subscribed to the Google Groups "Django developers"
Re: #12012 Logging: request for comments
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.