Re: Something.is_live instead of implementation specific is_live settings
On Sunday, September 26, 2010, Yo-Yo Ma wrote: > 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. And we keep telling you that such a setting doesn't make much sense. The development server isn't special - it runs code the same way as any other server, just without the overhead of a full production server. I can't see any compelling reason to embed a special 'development mode' status into the development server. After all, you can develop Django code without using the dev server. If you want to force DEBUG=True when you use the dev server, you already can do this by specifying a different settings.py file when you start the dev server. This works right now, and doesn't require imbuing the dev server with special status. 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: four NoSQL backends you want? :)
On Sun, Sep 26, 2010 at 6:54 AM, Russell Keith-Magee wrote: > 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. Agreed. However, in its *current* state, the only guaranteed contributors you have are people who aren't trusted and the only contributor who has decision power is you. This constellation is dysfunctional and that's what I'm talking about. Your calling for expertise is the right thing to do. And my whole post said this: If your call for expertise is not successful the team stays dysfunctional (unless you acquire the required expertise yourself) and this means any further work on NoSQL support has a high chance of being wasted time. Note, I still want to get the file uploads patch into Django. I don't intend to completely stop contributing. It's just the current situation around the NoSQL project that I don't find very attractive. > 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. I think I misread that part. Here's a little listing of what's supported by the djangoappengine backend: http://www.allbuttonspressed.com/projects/djangoappengine I'm not sure if that's what you want to see or if it's too concise. The MongoDB backend has basically the same constraints except that it natively also supports __iexact, __istartswith, __endswith, and __iendswith (though, not very efficiently). It also adds a field for embedded documents. > So far, your contributions to Django consist of two things: > * Maintaining the non-rel fork > * A large proposal to change the way file uploads work. > > The file uploads patch has been through several drafts, consumed a lot > of my time, and still isn't in a trunk ready state. This doesn't lead > me to a position of trusting that your other work is trunk ready; and > the discussions that we've had (both on file uploads, and on earlier > iterations of noSQL) haven't led me to a position where I feel I can > trust that your design decisions are compatible with the general > philosophy of Django's core. There seems to be a communication problem (is it a mistake on my side?). You seem to expect a cleaned up trunk-ready patch for the file uploads feature. In my last email I thought it was clear that I expected to get feedback on the high-level end-user API before starting to clean up everything, improving the function/class naming, etc. I have more fundamental questions like: Should the "tag" be based on the path to the Form/Model/ModelAdmin class? BTW, on Thursday Jannis Leidel has started commenting on the proposal, too (thanks a lot!): http://code.djangoproject.com/ticket/13960 Bye, Waldemar -- You received this message because you are subscribed to the Goo
Re: four NoSQL backends you want? :)
On Sun, Sep 26, 2010 at 6:40 PM, Waldemar Kornewald wrote: > On Sun, Sep 26, 2010 at 6:54 AM, Russell Keith-Magee > wrote: >> 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. > > I think I misread that part. Here's a little listing of what's > supported by the djangoappengine backend: > http://www.allbuttonspressed.com/projects/djangoappengine > I'm not sure if that's what you want to see or if it's too concise. The "Supported and Unsupported features" section is pretty close to what I would like to see. If each of the candidate storage engines had a similar summary from the perspective of a query-refactor compatible backend, we'd be well on the way. If you can get review from others in the community, that would be even better. >> So far, your contributions to Django consist of two things: >> * Maintaining the non-rel fork >> * A large proposal to change the way file uploads work. >> >> The file uploads patch has been through several drafts, consumed a lot >> of my time, and still isn't in a trunk ready state. This doesn't lead >> me to a position of trusting that your other work is trunk ready; and >> the discussions that we've had (both on file uploads, and on earlier >> iterations of noSQL) haven't led me to a position where I feel I can >> trust that your design decisions are compatible with the general >> philosophy of Django's core. > > There seems to be a communication problem (is it a mistake on my > side?). You seem to expect a cleaned up trunk-ready patch for the file > uploads feature. In my last email I thought it was clear that I > expected to get feedback on the high-level end-user API before > starting to clean up everything, improving the function/class naming, > etc. I have more fundamental questions like: Should the "tag" be based > on the path to the Form/Model/ModelAdmin class? BTW, on Thursday > Jannis Leidel has started commenting on the proposal, too (thanks a > lot!): > http://code.djangoproject.com/ticket/13960 I don't know if there's a communication problem. I've told you my position. At the moment, when I see your file uploads proposal, I see a time sink. There is still a lot of design work required. We've already been through a couple of iterations, and I don't feel like we're really getting any closer to a final solution. My Django time is all volunteered. I need to use it maximize utility of that time. Time that I spend helping you finesse a design is time that I don't spend fixing bugs, committing features, or working on designs from others. I have made a judgement call that continuing to work on your file uploads proposal isn't an effective use of my time at present considering the time it will take to get the design finished, and the potential benefits of the change when it is introduced. In principle, I like the idea of having better support for external file stores. But I'm not the only core team member (or, for that matter, member of the Django community) that can provide feedback. If Jannis can help you get your design closer to being trunk-ready, then that's great. 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: #12012 Logging: request for comments
Hi, On Sep 25, 1:25 pm, Jannis Leidel wrote: > 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. I agree, the only problem I see (not having looked at the app refactor branch yet + having no idea in which direction it is heading) is that if the app class is allowed to import other stuff. Cause this might easily end in models (or whatever) being imported and as a result we can't guarantee that it would happen as early as startup.py (though if someone imports critical stuff there we might get the same unwanted results). Btw: Is there a wiki page describing exactly what the branch solves currently and which direction it will be heading? Another question that came into my mind, after reading http://www.reddit.com/r/Python/comments/ddkal/django_vs_web2py_what_do_you_use_and_why/c0zmxqz (actually the whole thread, but that's the relevant post): Is there an easy and nice way to attach some extra info (eg request) to the logging info? Especially since I can't pass the request down all way to 3rd party apps; but I still want it to be logged in context of the current request (for easier debugging etc). The example in the reddit link isn't really convincing me -- especially since django doesn't put the request and other info into threadlocals. Regards, Florian -- 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 Sun, Sep 26, 2010 at 8:45 PM, Florian Apolloner wrote: > Hi, > Another question that came into my mind, after reading > http://www.reddit.com/r/Python/comments/ddkal/django_vs_web2py_what_do_you_use_and_why/c0zmxqz > (actually the whole thread, but that's the relevant post): Is there an > easy and nice way to attach some extra info (eg request) to the > logging info? Especially since I can't pass the request down all way > to 3rd party apps; but I still want it to be logged in context of the > current request (for easier debugging etc). The example in the reddit > link isn't really convincing me -- especially since django doesn't put > the request and other info into threadlocals. Yes, there is, and the logging calls I've included in the patch on #12012 make use of it. All the logging calls take an 'extra' parameter which can be used to insert relevant context into the logging call, and can be used in a custom formatter. In all the logging calls registering 4XX and 5XX messages, I've included the current request as extra context. 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: #12012 Logging: request for comments
Hi, On Sep 26, 2:55 pm, Russell Keith-Magee wrote: > Yes, there is, and the logging calls I've included in the patch on > #12012 make use of it. All the logging calls take an 'extra' parameter > which can be used to insert relevant context into the logging call, > and can be used in a custom formatter. In all the logging calls > registering 4XX and 5XX messages, I've included the current request as > extra context. I am aware of those; but let's imagine a 3rd party library which has no idea what a request is. In my logs I still want to know the request (even if it's just for formatting purposes…); so I am looking for a way to attach request specific info to __all__ logging calls done in one request __without__ adding it to the logging call. Florian -- 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 25 September 2010 19:47, Carl Meyer wrote: > 1. Reusable apps overuse GenericForeignKey. GFKs are inefficient and > smell bad. I seem to gradually be going away from GenericForeignKey and using "Glue"-models instead. App1, model1, is connected to App2, model2 via App3, Glue-model3, which has foreign-keys to model1 and model2, and sometimes a little extra. App1 and App2 need not know about eachother at all that way. I'm considering making my own tagging-module this way, as tags *is* one of the reusable apps that is useful to connect to more than one model in a project. Ditto for comments. HM -- 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 26.09.2010, at 14:45, Florian Apolloner wrote: > Hi, > > On Sep 25, 1:25 pm, Jannis Leidel wrote: >> 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. > > I agree, the only problem I see (not having looked at the app refactor > branch yet + having no idea in which direction it is heading) is that > if the app class is allowed to import other stuff. Cause this might > easily end in models (or whatever) being imported and as a result we > can't guarantee that it would happen as early as startup.py (though if > someone imports critical stuff there we might get the same unwanted > results). Not sure I understand the problem, the app instances are initialized by the app cache, at the same time as the proposed logging patch would import the startup modules. > Btw: Is there a wiki page describing exactly what the branch > solves currently and which direction it will be heading? Arthur wrote multiple status mails, please search the list archives. 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.
#12991 Adding support for unittest2: request for review
Hi all, I've just uploaded a patch for #12991, adding support for unittest2 to Django. This is a very big patch (500kb, 12k lines). For this reason, I've uploaded the patch compressed. Trac won't allow attachments greater than 200k, and given past history, large diffs break Trac anyway. However, the patch consists entirely of little changes. It does the following: * Introduces a copy of the unittest2 0.5.1 library to django.utils * Modify Django's imports to use "django.utils.unittest", rather than "import unittest" * Introducing the use of the @skipIf decorator for various DB and library-specific tests * Updating all the deprecated assertions, like failIf, failUnless, assert_, assertEquals, etc. If anyone can spare the time, I'd appreciate you taking this patch for a spin. This needs to be tested on as many Python versions as possible; I've validated that it works on Python 2.6, but it needs to work on Python 2.4, 2.5 and 2.7 as well, and I don't have ready access to machines with those setups. The patch also needs to be tested when unittest2 has been installed locally. If a locally installed version is present (or you have Python 2.7), that version will be used in preference to Django's builtin version. 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: proposal for lazy foreignkeys
Hi all, My 2 cents. I think the fact that you cannot have Foreign Keys link to specific models is a specific instance of a larger problem. It's currently not possible to make an app which has models with any kind of extended (subclassed) behavior. Say I create a tagging app. Now I might want to: * Create a foreign key to a specific taggable model (the problem at hand) * Add weights to tags * Add owners to tags * ... I think having this ability to extend models and pass the extended versions back into the reusable app is the key missing feature. Klaas On Sep 25, 7: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.
Re: proposal for lazy foreignkeys
Some more cases that would be important (not just ForeignKey): inheriting from the VirtualModel any kind of relationship to it (manytomany) ModelForms On Sep 25, 7: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.
Class based models
Hi all,
I'm looking for a bit of input for making Django's apps a bit more
extendable, either by modifying Django or (preferably) by coming up
with a common language on top op Django. The main painpoint are
extendable models. The idea of 'extendable' is that models from
reusable apps can be extended in any concrete project. The reusable
apps should refer to their own models in such a way that they will get
the concrete implementation (extension).
Class based models if you will.
Context can be found here:
http://groups.google.com/group/django-users/browse_thread/thread/22875fd287d0aa81/313b7bb67f24ad2f
Currently, apps usually refer to their own models by simply importing
them from models.py and referring to them. This obviously will not
work, so any solution will need some kind of registry, or instance of
"app". If "app" is an instance of a class referring to it can be done
in an extendible way (simply by using Python's inheritance mechanism).
I've put an example of this approach here:
http://bitbucket.org/vanschelven/extendible_app_experiment/src/0862cecb358d
Which incorporates the above idea of an app class & instance in blog/
__init__.py.
abstract_blog/abstract_models.py and blog/models.py
The key sections are:
(in abstract_models)
def get_AbstractPage(self):
class AbstractPage(models.Model):
body = models.TextField()
category = models.ForeignKey(self.app.models.Category)
class Meta:
abstract = True
#app_label = 'abstract_blog'
return AbstractPage
AbstractPage = property(get_AbstractPage)
(in models)
def get_Category(self):
class Category(self.AbstractCategory):
some_added_field = models.IntegerField()
return Category
Category = property(get_Category)
As you can see, it is possible to refer to "the apps real
implementation of Category" (self.app.models.Category, or just
self.Category) from the abstract model. Less neat: the cruft that's
needed to pass self into AbstractPage for reference (3 lines per
class: def, return & property).
In a more recent version I've managed to factor those lines away at
the cost of a lot of magic.
http://bitbucket.org/vanschelven/extendible_app_experiment/src/2b8eb68e8ee5
class AbstractModels(object):
#...
class AbstractPage(shmodels.Model):
body = shmodels.TextField()
category =
shmodels.ForeignKey(Zelf("app.models.Category"))
Neet uh? Self referral without an actual introduction of "self".
I may look for the general case of Zelf & Zelf2 and shmodels and
whatever... but I'd like to know that this is a path worth following.
In other words: am I missing really obvious, more simple solutions
here?
ciao,
Klaas
--
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 September 2010 08:16, Russell Keith-Magee wrote: > 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? Well naturally you can't log what happens in the settings-file itself :) I currently import logging at the end of settings.py but just before importing local settings files, so that I can log the specifics of the local settings. HM -- 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 Sep 26, 4:13 pm, Jannis Leidel wrote: > On 26.09.2010, at 14:45, Florian Apolloner wrote: > Not sure I understand the problem, the app instances are initialized by the > app cache, at the same time as the proposed logging patch would import the > startup modules. Jupp, my mistake -- nevermind. Florian -- 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: Something.is_live instead of implementation specific is_live settings
Ok, understood. All I wanted was discussion (or dismissal by simple matter of reason as your latest reply and my subsequent new understanding of the dev server's relationship to an application implies) about my original post. The thread started out with Jacob basically saying, "there's your solution, simple as that..." without even basically understanding my question, or reading it for that matter. Again, I apologize for the now 22 post long digression. On Sep 26, 1:52 am, Russell Keith-Magee wrote: > On Sunday, September 26, 2010, Yo-Yo Ma wrote: > > 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. > > And we keep telling you that such a setting doesn't make much sense. > > The development server isn't special - it runs code the same way as > any other server, just without the overhead of a full production > server. I can't see any compelling reason to embed a special > 'development mode' status into the development server. After all, you > can develop Django code without using the dev server. > > If you want to force DEBUG=True when you use the dev server, you > already can do this by specifying a different settings.py file when > you start the dev server. This works right now, and doesn't require > imbuing the dev server with special status. > > 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: #12012 Logging: request for comments
On Sep 26, 2:16 pm, Florian Apolloner wrote: > I am aware of those; but let's imagine a 3rd party library which has > no idea what a request is. In my logs I still want to know the request > (even if it's just for formatting purposes…); so I am looking for a > way to attach request specific info to __all__ logging calls done in > one request __without__ adding it to the logging call. You might be interested in this blog post: http://plumberjack.blogspot.com/2010/09/configuring-logging-for-web.html which solves the problem you mention (attaching request-specific info, to all logging calls in a request, including calls made in 3rd party libraries you use, without having to add "extra" to logging calls). However, it requires thread-locals, which for some reason the Django core team seem to be against: http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser You might regard the rest of this post OT, but ... I haven't seen any detailed evidence for the "huge threat" mentioned in that Wiki page. In fact, Graham Dumpleton, author of mod-wsgi, in this post, seems to be saying that it's not such a security threat that you need to rule out use of thread-locals: http://groups.google.com/group/django-users/msg/eb686bf30a7e4c26 To me, Graham seems right on the money. Of course, if the core team (or any one else) can point to any known exploits which take advantage of flaws in Python's thread-locals implementation, that would settle things right away :-) Even then, the answer would be to fix the hole in Python. Also - even if Django itself doesn't use thread-locals, can you be sure that any third-party library you are using doesn't do so under the covers? Regards, Vinay Sajip -- 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: #12991 Adding support for unittest2: request for review
I've run it on Python 2.4 & 2.5 (Ubuntu, sqlite DB) with no problems.
I do have some feedback on the @skipIfDB addition: I'd really like if this
could be used to distinguish between the different MySQL storage backends.
>From a very brief look it seems like currently there are a bunch of tests
skipped when the DB backend is MySQL, under the assumption that MySQL does
not have transaction support. However MySQL does have transaction support
when the InnoDB storage engine is used, so it would be nice if these tests
were only skipped when the MySQL/MyISAM combination were in use, not when
MySQL/InnoDB was used.
Similarly there are a bunch of tests that fail or produce errors when the
MySQL/InnoDB combination is in use, because that combination does not
support forward foreign-key references when loading fixtures. It's not ideal
to skip a bunch of tests for function that really should be tested on this
combination (aggregates, for example), but for now at least the fixtures
used by these tests do not allow them to pass on MySQL/InnoDB, so they might
as well just be skipped. I have quit ever trying to run the full Django test
suite using MySQL/InnoDB because there are just too many "known failures"
there. It would be nice if the addition of @skipIfDB improved that. (For
that matter I also never run the full suite with MySQL/MyISAM because the
lack of transaction support with that combo makes it just too slow to run
the full suite, but I don't know of any way to improve that situation.)
One difficulty in adding this extra check is that it is hard to know for
sure what storage engine is in use. If the database definition dict includes
'OPTIONS': { "init_command": "SET storage_engine=" } then we know
the engine is in use. If not, the default configured engine for
the MySQL server will be used, and that could be either one. I'd be inclined
to say if you want to skip tests based on a particular storage engine being
used, then you need to make it explicit in the test settings what engine you
are using. So I'd be happy if this @skipIfDB threw an error if it was asked
to skip based on storage engine but could not find in the test settings what
storage engine was being used.
Another difficulty is figuring out how to nicely specify this additional
requirement. Have not given that a whole lot of thought yet. Right now the
@skipIfDB takes a simple string (matched against DB ENGINE key) or iterable
of strings. Supporting querying both ENGINE and OPTIONS, and allowing for
more than one to be listed, might get a bit ugly. I am curious why the
iterable option here was added -- are there a lot of cases in the current
suite where tests need to be skipped on a set of DB backends and not just
one?
Karen
--
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 Mon, Sep 27, 2010 at 4:28 AM, Vinay Sajip wrote: > On Sep 26, 2:16 pm, Florian Apolloner wrote: >> I am aware of those; but let's imagine a 3rd party library which has >> no idea what a request is. In my logs I still want to know the request >> (even if it's just for formatting purposes…); so I am looking for a >> way to attach request specific info to __all__ logging calls done in >> one request __without__ adding it to the logging call. > > You might be interested in this blog post: > > http://plumberjack.blogspot.com/2010/09/configuring-logging-for-web.html > > which solves the problem you mention (attaching request-specific info, > to all logging calls in a request, including calls made in 3rd party > libraries you use, without having to add "extra" to logging calls). > > However, it requires thread-locals, which for some reason the Django > core team seem to be against: > > http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser > > You might regard the rest of this post OT, but ... I haven't seen any > detailed evidence for the "huge threat" mentioned in that Wiki page. > In fact, Graham Dumpleton, author of mod-wsgi, in this post, seems to > be saying that it's not such a security threat that you need to rule > out use of thread-locals: > > http://groups.google.com/group/django-users/msg/eb686bf30a7e4c26 > > To me, Graham seems right on the money. Of course, if the core team > (or any one else) can point to any known exploits which take advantage > of flaws in Python's thread-locals implementation, that would settle > things right away :-) Even then, the answer would be to fix the hole > in Python. Is there a known exploit inherent in the use of threadlocals? No. Django's position is entirely defensive. The potential for security issues associated with threadlocals is entirely a function of how they are used. Threadlocals are a vector by which it is possible, either intentionally or accidentally, to allow data to leak from one request to another. This is the starting point of an exploit. Since avoiding this exploit requires you to actively look for potential ways that your threadlocal usage can be abused, Django has made an architectural decision to discourage their use. On top of that, there is the purely architectural argument: threadlocals are a global variable by any other name. They increase coupling in the systems in which they are used. If an engineer came to you and proposed a design that relied upon the use of global variables, they would be soundly ridiculed; but for some reason, calling that same global variable a "threadlocal" makes it socially acceptable. It is entirely possible to build a robust, testable web system without the use of threadlocals. You just need to be thorough in your design work. > Also - even if Django itself doesn't use thread-locals, can you be > sure that any third-party library you are using doesn't do so under > the covers? Truth be told, Django *does* use threadlocals in a couple of very specific circumstances. These uses have been extensively audited to make sure there is no exploit hidden in them. It is possible to use threadlocals in a safe way. If people want to pursue these architectural options, they are free to do so -- there is nothing in Django actively hobbling the use of threadlocals. It's just not a practice that we (as a project) are going to recommend. 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: #12991 Adding support for unittest2: request for review
On Mon, Sep 27, 2010 at 6:24 AM, Karen Tracey wrote:
> I've run it on Python 2.4 & 2.5 (Ubuntu, sqlite DB) with no problems.
>
> I do have some feedback on the @skipIfDB addition: I'd really like if this
> could be used to distinguish between the different MySQL storage backends.
> From a very brief look it seems like currently there are a bunch of tests
> skipped when the DB backend is MySQL, under the assumption that MySQL does
> not have transaction support. However MySQL does have transaction support
> when the InnoDB storage engine is used, so it would be nice if these tests
> were only skipped when the MySQL/MyISAM combination were in use, not when
> MySQL/InnoDB was used.
>
> Similarly there are a bunch of tests that fail or produce errors when the
> MySQL/InnoDB combination is in use, because that combination does not
> support forward foreign-key references when loading fixtures. It's not ideal
> to skip a bunch of tests for function that really should be tested on this
> combination (aggregates, for example), but for now at least the fixtures
> used by these tests do not allow them to pass on MySQL/InnoDB, so they might
> as well just be skipped. I have quit ever trying to run the full Django test
> suite using MySQL/InnoDB because there are just too many "known failures"
> there. It would be nice if the addition of @skipIfDB improved that. (For
> that matter I also never run the full suite with MySQL/MyISAM because the
> lack of transaction support with that combo makes it just too slow to run
> the full suite, but I don't know of any way to improve that situation.)
>
> One difficulty in adding this extra check is that it is hard to know for
> sure what storage engine is in use. If the database definition dict includes
> 'OPTIONS': { "init_command": "SET storage_engine=" } then we know
> the engine is in use. If not, the default configured engine for
> the MySQL server will be used, and that could be either one. I'd be inclined
> to say if you want to skip tests based on a particular storage engine being
> used, then you need to make it explicit in the test settings what engine you
> are using. So I'd be happy if this @skipIfDB threw an error if it was asked
> to skip based on storage engine but could not find in the test settings what
> storage engine was being used.
The problem with this approach is that you can configure MySQL to use
InnoDB by default for table creation, so there won't necessarily be
any Django settings providing evidence that transactions are
available.
> Another difficulty is figuring out how to nicely specify this additional
> requirement. Have not given that a whole lot of thought yet. Right now the
> @skipIfDB takes a simple string (matched against DB ENGINE key) or iterable
> of strings. Supporting querying both ENGINE and OPTIONS, and allowing for
> more than one to be listed, might get a bit ugly. I am curious why the
> iterable option here was added -- are there a lot of cases in the current
> suite where tests need to be skipped on a set of DB backends and not just
> one?
The use case for the iterable is everywhere that PostgreSQL is the
skip target, because we have 2 backends that need to be skipped.
I'm in agreement that the ENGINE-string based skipIfDB isn't a
particularly robust test. If nothing else, it means that if a user
writes a third-party engine for MySQL (or anything else) in order to
change some subtle behavior, the test suite won't be any use to them,
because the string match won't cause the appropriate tests to be
skipped.
One thought here would be to introduce a variable on the backend
itself that is a 'db identifier' - i.e., a string that clearly
identifies the vendor, independent of the path that has been used to
install the backend. So, for example, a check for
connection.db_identifier = 'postgresql' would always tell you that
you're dealing with PostgreSQL, regardless of the import path to the
actual backend.
This has three potential benefits.
1. We can avoid the need for the iterable skipIfDB version.
2. We enable writers of third-party backend for Django supported
databases to benefit from test skip annotations
3. We provide a name that can be used for backend-specific features,
such as the index-hinting proposal that has been floating around.
However, this still doesn't address the InnoDB problem, or provide any
support for completely external backends -- for example, the writers
of the DB2 backend can't use Django's test suite, because the DB2
backend isn't specifically named in Django's source code (nor should
it).
It also occurs to me that in most cases, the skip should actually be
based on capabilities, not on the backend itself. We should be
skipping because the backend doesn't support transactions, or because
the backend doesn't allow forward references in fixtures, not because
the backend is MySQL.
connection.features already provides one place to check whether
certain features are available. It would be a relatively simp
Re: #12991 Adding support for unittest2: request for review
On Sun, Sep 26, 2010 at 8:44 PM, Russell Keith-Magee
wrote:
> On Mon, Sep 27, 2010 at 6:24 AM, Karen Tracey wrote:
>> I've run it on Python 2.4 & 2.5 (Ubuntu, sqlite DB) with no problems.
>>
>> I do have some feedback on the @skipIfDB addition: I'd really like if this
>> could be used to distinguish between the different MySQL storage backends.
>> From a very brief look it seems like currently there are a bunch of tests
>> skipped when the DB backend is MySQL, under the assumption that MySQL does
>> not have transaction support. However MySQL does have transaction support
>> when the InnoDB storage engine is used, so it would be nice if these tests
>> were only skipped when the MySQL/MyISAM combination were in use, not when
>> MySQL/InnoDB was used.
>>
>> Similarly there are a bunch of tests that fail or produce errors when the
>> MySQL/InnoDB combination is in use, because that combination does not
>> support forward foreign-key references when loading fixtures. It's not ideal
>> to skip a bunch of tests for function that really should be tested on this
>> combination (aggregates, for example), but for now at least the fixtures
>> used by these tests do not allow them to pass on MySQL/InnoDB, so they might
>> as well just be skipped. I have quit ever trying to run the full Django test
>> suite using MySQL/InnoDB because there are just too many "known failures"
>> there. It would be nice if the addition of @skipIfDB improved that. (For
>> that matter I also never run the full suite with MySQL/MyISAM because the
>> lack of transaction support with that combo makes it just too slow to run
>> the full suite, but I don't know of any way to improve that situation.)
>>
>> One difficulty in adding this extra check is that it is hard to know for
>> sure what storage engine is in use. If the database definition dict includes
>> 'OPTIONS': { "init_command": "SET storage_engine=" } then we know
>> the engine is in use. If not, the default configured engine for
>> the MySQL server will be used, and that could be either one. I'd be inclined
>> to say if you want to skip tests based on a particular storage engine being
>> used, then you need to make it explicit in the test settings what engine you
>> are using. So I'd be happy if this @skipIfDB threw an error if it was asked
>> to skip based on storage engine but could not find in the test settings what
>> storage engine was being used.
>
> The problem with this approach is that you can configure MySQL to use
> InnoDB by default for table creation, so there won't necessarily be
> any Django settings providing evidence that transactions are
> available.
>
>> Another difficulty is figuring out how to nicely specify this additional
>> requirement. Have not given that a whole lot of thought yet. Right now the
>> @skipIfDB takes a simple string (matched against DB ENGINE key) or iterable
>> of strings. Supporting querying both ENGINE and OPTIONS, and allowing for
>> more than one to be listed, might get a bit ugly. I am curious why the
>> iterable option here was added -- are there a lot of cases in the current
>> suite where tests need to be skipped on a set of DB backends and not just
>> one?
>
> The use case for the iterable is everywhere that PostgreSQL is the
> skip target, because we have 2 backends that need to be skipped.
>
> I'm in agreement that the ENGINE-string based skipIfDB isn't a
> particularly robust test. If nothing else, it means that if a user
> writes a third-party engine for MySQL (or anything else) in order to
> change some subtle behavior, the test suite won't be any use to them,
> because the string match won't cause the appropriate tests to be
> skipped.
>
> One thought here would be to introduce a variable on the backend
> itself that is a 'db identifier' - i.e., a string that clearly
> identifies the vendor, independent of the path that has been used to
> install the backend. So, for example, a check for
> connection.db_identifier = 'postgresql' would always tell you that
> you're dealing with PostgreSQL, regardless of the import path to the
> actual backend.
>
> This has three potential benefits.
>
> 1. We can avoid the need for the iterable skipIfDB version.
> 2. We enable writers of third-party backend for Django supported
> databases to benefit from test skip annotations
> 3. We provide a name that can be used for backend-specific features,
> such as the index-hinting proposal that has been floating around.
>
> However, this still doesn't address the InnoDB problem, or provide any
> support for completely external backends -- for example, the writers
> of the DB2 backend can't use Django's test suite, because the DB2
> backend isn't specifically named in Django's source code (nor should
> it).
>
> It also occurs to me that in most cases, the skip should actually be
> based on capabilities, not on the backend itself. We should be
> skipping because the backend doesn't support transactions, or because
> the backend doesn't allow forward re
Re: #12991 Adding support for unittest2: request for review
On Sep 26, 2010, at 7:44 PM, Russell Keith-Magee wrote:
> On Mon, Sep 27, 2010 at 6:24 AM, Karen Tracey wrote:
>> I've run it on Python 2.4 & 2.5 (Ubuntu, sqlite DB) with no problems.
>>
>> I do have some feedback on the @skipIfDB addition: I'd really like if this
>> could be used to distinguish between the different MySQL storage backends.
>> From a very brief look it seems like currently there are a bunch of tests
>> skipped when the DB backend is MySQL, under the assumption that MySQL does
>> not have transaction support. However MySQL does have transaction support
>> when the InnoDB storage engine is used, so it would be nice if these tests
>> were only skipped when the MySQL/MyISAM combination were in use, not when
>> MySQL/InnoDB was used.
>>
>> Similarly there are a bunch of tests that fail or produce errors when the
>> MySQL/InnoDB combination is in use, because that combination does not
>> support forward foreign-key references when loading fixtures. It's not ideal
>> to skip a bunch of tests for function that really should be tested on this
>> combination (aggregates, for example), but for now at least the fixtures
>> used by these tests do not allow them to pass on MySQL/InnoDB, so they might
>> as well just be skipped. I have quit ever trying to run the full Django test
>> suite using MySQL/InnoDB because there are just too many "known failures"
>> there. It would be nice if the addition of @skipIfDB improved that. (For
>> that matter I also never run the full suite with MySQL/MyISAM because the
>> lack of transaction support with that combo makes it just too slow to run
>> the full suite, but I don't know of any way to improve that situation.)
>>
>> One difficulty in adding this extra check is that it is hard to know for
>> sure what storage engine is in use. If the database definition dict includes
>> 'OPTIONS': { "init_command": "SET storage_engine=" } then we know
>> the engine is in use. If not, the default configured engine for
>> the MySQL server will be used, and that could be either one. I'd be inclined
>> to say if you want to skip tests based on a particular storage engine being
>> used, then you need to make it explicit in the test settings what engine you
>> are using. So I'd be happy if this @skipIfDB threw an error if it was asked
>> to skip based on storage engine but could not find in the test settings what
>> storage engine was being used.
>
> The problem with this approach is that you can configure MySQL to use
> InnoDB by default for table creation, so there won't necessarily be
> any Django settings providing evidence that transactions are
> available.
>
>> Another difficulty is figuring out how to nicely specify this additional
>> requirement. Have not given that a whole lot of thought yet. Right now the
>> @skipIfDB takes a simple string (matched against DB ENGINE key) or iterable
>> of strings. Supporting querying both ENGINE and OPTIONS, and allowing for
>> more than one to be listed, might get a bit ugly. I am curious why the
>> iterable option here was added -- are there a lot of cases in the current
>> suite where tests need to be skipped on a set of DB backends and not just
>> one?
>
> The use case for the iterable is everywhere that PostgreSQL is the
> skip target, because we have 2 backends that need to be skipped.
>
> I'm in agreement that the ENGINE-string based skipIfDB isn't a
> particularly robust test. If nothing else, it means that if a user
> writes a third-party engine for MySQL (or anything else) in order to
> change some subtle behavior, the test suite won't be any use to them,
> because the string match won't cause the appropriate tests to be
> skipped.
>
> One thought here would be to introduce a variable on the backend
> itself that is a 'db identifier' - i.e., a string that clearly
> identifies the vendor, independent of the path that has been used to
> install the backend. So, for example, a check for
> connection.db_identifier = 'postgresql' would always tell you that
> you're dealing with PostgreSQL, regardless of the import path to the
> actual backend.
>
> This has three potential benefits.
>
> 1. We can avoid the need for the iterable skipIfDB version.
> 2. We enable writers of third-party backend for Django supported
> databases to benefit from test skip annotations
> 3. We provide a name that can be used for backend-specific features,
> such as the index-hinting proposal that has been floating around.
>
> However, this still doesn't address the InnoDB problem, or provide any
> support for completely external backends -- for example, the writers
> of the DB2 backend can't use Django's test suite, because the DB2
> backend isn't specifically named in Django's source code (nor should
> it).
>
> It also occurs to me that in most cases, the skip should actually be
> based on capabilities, not on the backend itself. We should be
> skipping because the backend doesn't support transactions, or because
> the backend doesn't allow forw
Re: #12991 Adding support for unittest2: request for review
On Monday, September 27, 2010, Patrick Altman wrote:
>
> On Sep 26, 2010, at 7:44 PM, Russell Keith-Magee wrote:
>
>> On Mon, Sep 27, 2010 at 6:24 AM, Karen Tracey wrote:
>>> I've run it on Python 2.4 & 2.5 (Ubuntu, sqlite DB) with no problems.
>>>
>>> I do have some feedback on the @skipIfDB addition: I'd really like if this
>>> could be used to distinguish between the different MySQL storage backends.
>>> From a very brief look it seems like currently there are a bunch of tests
>>> skipped when the DB backend is MySQL, under the assumption that MySQL does
>>> not have transaction support. However MySQL does have transaction support
>>> when the InnoDB storage engine is used, so it would be nice if these tests
>>> were only skipped when the MySQL/MyISAM combination were in use, not when
>>> MySQL/InnoDB was used.
>>>
>>> Similarly there are a bunch of tests that fail or produce errors when the
>>> MySQL/InnoDB combination is in use, because that combination does not
>>> support forward foreign-key references when loading fixtures. It's not ideal
>>> to skip a bunch of tests for function that really should be tested on this
>>> combination (aggregates, for example), but for now at least the fixtures
>>> used by these tests do not allow them to pass on MySQL/InnoDB, so they might
>>> as well just be skipped. I have quit ever trying to run the full Django test
>>> suite using MySQL/InnoDB because there are just too many "known failures"
>>> there. It would be nice if the addition of @skipIfDB improved that. (For
>>> that matter I also never run the full suite with MySQL/MyISAM because the
>>> lack of transaction support with that combo makes it just too slow to run
>>> the full suite, but I don't know of any way to improve that situation.)
>>>
>>> One difficulty in adding this extra check is that it is hard to know for
>>> sure what storage engine is in use. If the database definition dict includes
>>> 'OPTIONS': { "init_command": "SET storage_engine=" } then we know
>>> the engine is in use. If not, the default configured engine for
>>> the MySQL server will be used, and that could be either one. I'd be inclined
>>> to say if you want to skip tests based on a particular storage engine being
>>> used, then you need to make it explicit in the test settings what engine you
>>> are using. So I'd be happy if this @skipIfDB threw an error if it was asked
>>> to skip based on storage engine but could not find in the test settings what
>>> storage engine was being used.
>>
>> The problem with this approach is that you can configure MySQL to use
>> InnoDB by default for table creation, so there won't necessarily be
>> any Django settings providing evidence that transactions are
>> available.
>>
>>> Another difficulty is figuring out how to nicely specify this additional
>>> requirement. Have not given that a whole lot of thought yet. Right now the
>>> @skipIfDB takes a simple string (matched against DB ENGINE key) or iterable
>>> of strings. Supporting querying both ENGINE and OPTIONS, and allowing for
>>> more than one to be listed, might get a bit ugly. I am curious why the
>>> iterable option here was added -- are there a lot of cases in the current
>>> suite where tests need to be skipped on a set of DB backends and not just
>>> one?
>>
>> The use case for the iterable is everywhere that PostgreSQL is the
>> skip target, because we have 2 backends that need to be skipped.
>>
>> I'm in agreement that the ENGINE-string based skipIfDB isn't a
>> particularly robust test. If nothing else, it means that if a user
>> writes a third-party engine for MySQL (or anything else) in order to
>> change some subtle behavior, the test suite won't be any use to them,
>> because the string match won't cause the appropriate tests to be
>> skipped.
>>
>> One thought here would be to introduce a variable on the backend
>> itself that is a 'db identifier' - i.e., a string that clearly
>> identifies the vendor, independent of the path that has been used to
>> install the backend. So, for example, a check for
>> connection.db_identifier = 'postgresql' would always tell you that
>> you're dealing with PostgreSQL, regardless of the import path to the
>> actual backend.
>>
>> This has three potential benefits.
>>
>> 1. We can avoid the need for the iterI like the idea of connection.features
>> for this type of thing.
>
> In fact, it doesn't seem that there is anything preventing children of
> BaseDatabaseFeatures to implement properties instead of just static variables
> that actually connects to the configured database connection and queries the
> backend specific metadata (e.g. what storage engine am I using?).
Agreed; although there is a mild performance concern if we do that.
Hitting the database to determine if a feature is available isn't an
expensive operation in itself, but if is repeated a lot of times, the
overhead could be considerable.
That's not a reason to avoid the technique, of course; just a gotcha
to watch out f
Re: #12991 Adding support for unittest2: request for review
I just ran it on Python 2.4, 2.5, 2.6, and 2.7 with each of SQLite, MySQL,
and PostgreSQL on Debian with no problems.
Thanks for the work you put into this, Russell!
On Sun, Sep 26, 2010 at 6:24 PM, Karen Tracey wrote:
> I've run it on Python 2.4 & 2.5 (Ubuntu, sqlite DB) with no problems.
>
> I do have some feedback on the @skipIfDB addition: I'd really like if this
> could be used to distinguish between the different MySQL storage backends.
> From a very brief look it seems like currently there are a bunch of tests
> skipped when the DB backend is MySQL, under the assumption that MySQL does
> not have transaction support. However MySQL does have transaction support
> when the InnoDB storage engine is used, so it would be nice if these tests
> were only skipped when the MySQL/MyISAM combination were in use, not when
> MySQL/InnoDB was used.
>
> Similarly there are a bunch of tests that fail or produce errors when the
> MySQL/InnoDB combination is in use, because that combination does not
> support forward foreign-key references when loading fixtures. It's not ideal
> to skip a bunch of tests for function that really should be tested on this
> combination (aggregates, for example), but for now at least the fixtures
> used by these tests do not allow them to pass on MySQL/InnoDB, so they might
> as well just be skipped. I have quit ever trying to run the full Django test
> suite using MySQL/InnoDB because there are just too many "known failures"
> there. It would be nice if the addition of @skipIfDB improved that. (For
> that matter I also never run the full suite with MySQL/MyISAM because the
> lack of transaction support with that combo makes it just too slow to run
> the full suite, but I don't know of any way to improve that situation.)
>
> One difficulty in adding this extra check is that it is hard to know for
> sure what storage engine is in use. If the database definition dict includes
> 'OPTIONS': { "init_command": "SET storage_engine=" } then we know
> the engine is in use. If not, the default configured engine for
> the MySQL server will be used, and that could be either one. I'd be inclined
> to say if you want to skip tests based on a particular storage engine being
> used, then you need to make it explicit in the test settings what engine you
> are using. So I'd be happy if this @skipIfDB threw an error if it was asked
> to skip based on storage engine but could not find in the test settings what
> storage engine was being used.
>
> Another difficulty is figuring out how to nicely specify this additional
> requirement. Have not given that a whole lot of thought yet. Right now the
> @skipIfDB takes a simple string (matched against DB ENGINE key) or iterable
> of strings. Supporting querying both ENGINE and OPTIONS, and allowing for
> more than one to be listed, might get a bit ugly. I am curious why the
> iterable option here was added -- are there a lot of cases in the current
> suite where tests need to be skipped on a set of DB backends and not just
> one?
>
> Karen
>
>
>
>
>
>
>
>
>
> --
> 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.
>
--
*
Chuck Harmston
*
ch...@chuckharmston.com
http://chuckharmston.com
--
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: Class based models
I may be dense but is this the functional equiv of cobtrib.comments
get_model()?
On Sep 26, 8:28 am, Klaas van Schelven
wrote:
> Hi all,
>
> I'm looking for a bit of input for making Django's apps a bit more
> extendable, either by modifying Django or (preferably) by coming up
> with a common language on top op Django. The main painpoint are
> extendable models. The idea of 'extendable' is that models from
> reusable apps can be extended in any concrete project. The reusable
> apps should refer to their own models in such a way that they will get
> the concrete implementation (extension).
> Class based models if you will.
>
> Context can be found
> here:http://groups.google.com/group/django-users/browse_thread/thread/2287...
>
> Currently, apps usually refer to their own models by simply importing
> them from models.py and referring to them. This obviously will not
> work, so any solution will need some kind of registry, or instance of
> "app". If "app" is an instance of a class referring to it can be done
> in an extendible way (simply by using Python's inheritance mechanism).
>
> I've put an example of this approach
> here:http://bitbucket.org/vanschelven/extendible_app_experiment/src/0862ce...
>
> Which incorporates the above idea of an app class & instance in blog/
> __init__.py.
>
> abstract_blog/abstract_models.py and blog/models.py
>
> The key sections are:
> (in abstract_models)
>
> def get_AbstractPage(self):
> class AbstractPage(models.Model):
> body = models.TextField()
> category = models.ForeignKey(self.app.models.Category)
>
> class Meta:
> abstract = True
> #app_label = 'abstract_blog'
> return AbstractPage
> AbstractPage = property(get_AbstractPage)
>
> (in models)
> def get_Category(self):
> class Category(self.AbstractCategory):
> some_added_field = models.IntegerField()
> return Category
> Category = property(get_Category)
>
> As you can see, it is possible to refer to "the apps real
> implementation of Category" (self.app.models.Category, or just
> self.Category) from the abstract model. Less neat: the cruft that's
> needed to pass self into AbstractPage for reference (3 lines per
> class: def, return & property).
>
> In a more recent version I've managed to factor those lines away at
> the cost of a lot of
> magic.http://bitbucket.org/vanschelven/extendible_app_experiment/src/2b8eb6...
>
> class AbstractModels(object):
> #...
> class AbstractPage(shmodels.Model):
> body = shmodels.TextField()
> category =
> shmodels.ForeignKey(Zelf("app.models.Category"))
>
> Neet uh? Self referral without an actual introduction of "self".
>
> I may look for the general case of Zelf & Zelf2 and shmodels and
> whatever... but I'd like to know that this is a path worth following.
> In other words: am I missing really obvious, more simple solutions
> here?
>
> ciao,
> Klaas
--
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: #12991 Adding support for unittest2: request for review
On Monday, September 27, 2010, Chuck Harmston wrote: > I just ran it on Python 2.4, 2.5, 2.6, and 2.7 with each of SQLite, MySQL, > and PostgreSQL on Debian with no problems. Awesome! Thanks for that, Chuck. 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.
Application, tempaltetags and namespace
Hi all, I'm curious to know if it's planned in the future to force the use of the complete name of the applications and the templatestags. I'll explain myself. Imagine you have an application called hello.world with the following structure: hello.world/ setup.py hello/ world/ ... If you have an application called common and a templatags named featured_product, there's no way to it seems to force django to refer only to the complete name like that: hello.world.common and hello.world.common.featured_products it caused sometime some problems related to conflicting names and more than that, it means we are not completely explicit but magic. What do you think ? -- Mathieu Leduc-Hamel -- 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: Application, tempaltetags and namespace
On Mon, Sep 27, 2010 at 1:43 PM, Mathieu Leduc-Hamel wrote: > Hi all, > > I'm curious to know if it's planned in the future to force the use of > the complete name of the applications and the templatestags. I'll > explain myself. > > Imagine you have an application called > > hello.world > > with the following structure: > > hello.world/ > setup.py > hello/ > world/ > ... > > If you have an application called common and a templatags named > featured_product, there's no way to it seems to force django to refer > only to the complete name like that: > > hello.world.common > > and > > hello.world.common.featured_products > > it caused sometime some problems related to conflicting names and more > than that, it means we are not completely explicit but magic. > > What do you think ? There are two tickets related to this problem: #2539: Namespacing for template tags #12772: Loading by fully qualified path name Template tag namespacing has been accepted as an idea; it's just waiting on a trunk-ready patch. Loading by fully qualified path is currently marked DDN; On principle, the idea seems sound to me, but it requires more thought in terms of how the new loading scheme will interact with existing code. 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.
Proposal: Meta.required_together
You don't require health profiling information, but if they enter any,
they must enter it all.
Currently, the pattern is something like:
def clean(self):
if any((self.weight, self.height))
if not all((self.weight, self.height))
raise ValidationError("Uh oh!")
My proposal is to use:
class Meta:
required_together = ('weight', 'height')
This could be application-level of course and not enforced by the
database. The validation error could be something like: "If you enter
"weight", or "height", you must enter both.".
I'm not very well versed with SQL and DBs in general, but I have a
feeling that this has something to do with composite fields, if made
to be enforced at a DB level.
--
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 Sep 25, 7:46 pm, Antoni Aloy wrote: > > 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 > Hi, If you are concerned about logging performance for your particular application then you might want to consider NonblockingLogHandler [1]. [1] http://www.somethinkodd.com/oddthinking/nonblocking-log-handler/ Regards -- Matthew Flanagan http://wadofstuff.blogspot.com > 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.
