GSoC 2007 - Object-Level Caching
Hello all! Continuing with the string of posts regarding this year's GSoC, I'm pleased to be working on new caching functionality for Django's ORM under the mentorship of Gary Wilson[1]! Big thanks to him and all the people from the community who made this possible. Now I've just got to hold up my end of the bargain ;) An updated version of my original proposal is available on Django's wiki[2] and the project repository is available from Google Project Hosting[3]. This project aims to condense common caching idioms into simple QuerySet methods that deal with cached data intelligently, refill expired cache, track instance modification/deletion, descend through relationships, and so on. I've tried to make it accommodate the most common use cases, be it dumping front-page news articles to cache or keeping user profile data on hand when rendering a more dynamic site, but I'd definitely love to hear about how cached data is really used out in the field. Currently, three QuerySet methods, .cache(), .cache_related(), and .cache_set() handle individual, relation, and aggregate data caching, respectively. Each can take arguments to specify options like expiry time. Signals are registered behind the scenes to sync the cache, and there's also a proposal for transactional caching. Generic relations will also benefit greatly from .cache_related(). More detail is available on the wiki page, but lots of the little issues that surround the implementation are still bouncing around in my head; the page is going to be expanding and mutating throughout the next few months, I'm sure. The timeline is a little underdeveloped, for one. Comments and criticisms are always welcome! The project itself is currently a single module which has a class derived from QuerySet with all of the new functionality, and a little hack to inject the .cache(), etc methods right back into QuerySet. It also ships with a project in which I'll be writing proper tests. Some sort of miniature cache-testing framework may be in order too. Eventually, perhaps it'll become fit for inclusion in the Django proper--but either way it doesn't require a huge amount of core modification. I'm also curious about the progress of QuerySet refactoring, which would understandably have a huge impact on the code I'm writing. Either way, this new code applies directly to a Django project I've been working on for the last while, so I have the motivation to maintain this project wherever it may go! Thanks, Paul Collier [1] http://gdub.wordpress.com/ [2] http://code.djangoproject.com/wiki/ObjectLevelCaching [3] http://code.google.com/p/django-object-level-caching/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
On May 28, 8:44 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:> > In short, I vote that it be changed to django-policy. I can't change > the URL in Google Code without starting a whole new project (and since > I already have issues in place, I'd rather not do that), but I can > change all the documentation and add a note explaining the > discrepancy. Sounds a bit too generic for me. I'd prefer something like "dynamic settings". Maybe you should just name it after an animal or a plant ;-) Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MEDIA_URL template tag/context processor/etc again
El mar, 29-05-2007 a las 08:15 +0800, Russell Keith-Magee escribió:
> I make that 5:3 - and not wanting to put a jackboot down on the throat
> of democracy, but #1278 has the support of 4 core developers,
> including the BDFL.
I never was good at maths :) And I didn't perform a really well measured
calculation :)
Anyway, now it's clear that we should go for {{ MEDIA_URL }} which means
that in a near future we'll have MEDIA_URL in templates, hurray! :)
Cheers,
Marc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: django-values -> django-policy?
Hmm, policy reminds me of a few pages of text with legal mumbo jumbo, like an acceptable use policy. We can go for something technical, like values, properties, entries, constraints, presets, ... or maybe it's time for something completely different. Let's call them "tefkav"s, as in, "The Entities Formerly Known As Values". Or something else that's actually funny. I'd say we wait for another couple of opinions and then let Marty decide which one is best. In the end the name is not going to be a show stopper for using them in a project. Simon On May 29, 8:52 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Tue, 2007-05-29 at 01:42 -0400, Max Battcher wrote: > > On 5/28/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > > > Maybe a combination of the two would be a bit better. "policyvalues"? > > > Indicating its usefulness in the scope of policies while still being > > > clear that its features only extend to the values. > > > When I think of Policies I think more of Constraints than Values, so > > django-policy-constraints doesn't sound that bad, just verbose. Or > > what about just django-constraints? > > The app doesn't *constrain* anything. It's a way to store a collection > of values, so the any name needs to probably be under the list of > synonyms for "value" in the thesaurus. > > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [Triagers/Core] About Stale Tickets
El mar, 29-05-2007 a las 10:53 +1000, Malcolm Tredinnick escribió: > I didn't respond to your first email about this over the weekend, > because the reply I originally wrote wasn't particularly polite. Thanks for not sending that one then ;) > At some point, you have to accept that this ticket can wait a bit longer. It's > not like no action is happening anywhere in Django. You are in the queue > of things to be processed and being in the queue is better than not > being in the queue, at least. I already run a patched django so I really can wait much longer. I was just worried of not having any reply on my previous requests about #1051. > There are many fish (bugs) in the sea here. Getting hung up on one > particular ticket isn't worth the stress. Uhm. I think I've never been stressed ;) > With best wishes, > Malcolm Really, thanks for such a concise reply (on both things: #1051 and triaging) that was exactly what I was looking for! Cheers, Marc --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
Registry? Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Optgroups from nested choices in newforms (discussion of patch on #4412)
I noticed a patch sitting on #4412 tonight which seems interesting but definitely needs a decision; the idea is that, rather than implementing a separate widget or set of widgets to handle grouping of options (via the HTML "optgroup" element), the Select and SelectMultiple widgets should look at the structure of 'choices -- if it has a nested structure of grouped choices, those should translate into optgroups in the rendered widget. Personally, I kind of like the simplicity of the approach and the fact that it handles this use case without needlessly multiplying widgets, so I'd give it a tentative +1. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
On 5/29/07, Derek Hoy <[EMAIL PROTECTED]> wrote: > > > Registry? +1 django-registry. -- Amit Upadhyay Vakao! +91-9820-295-512 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms captcha field
Thanks "itsnotvalid" and SmileyChris for your replys. Unfortunately "reCAPTCHA" does not fulfil my needs, because it has an english-only interface, and just english words - at least for the time being. I think, I'll have to do my own approach: * A directory containing small images for backgrounds * A directory containing various true-type fonts * A file containing predefined words * A switch whether to use random strings or the words-file * A directory containing pictures with some "noise" - e.g. an arc, some lines etc. which can be pasted on top of the word The resulting images will have random backgrounds, use different fonts and rotation for each character, and also some noise. And: SmileyChris, thanks for your code - I think, I'll use plenty of it :) Martin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 - Object-Level Caching
On Tue, 2007-05-29 at 07:37 +, Paul Collier wrote: > Hello all! > > Continuing with the string of posts regarding this year's GSoC, I'm > pleased to be working on new caching functionality for Django's ORM > under the mentorship of Gary Wilson[1]! Big thanks to him and all the > people from the community who made this possible. Now I've just got to > hold up my end of the bargain ;) > > An updated version of my original proposal is available on Django's > wiki[2] and the project repository is available from Google Project > Hosting[3]. > > This project aims to condense common caching idioms into simple > QuerySet methods that deal with cached data intelligently, refill > expired cache, track instance modification/deletion, descend through > relationships, and so on. I've tried to make it accommodate the most > common use cases, be it dumping front-page news articles to cache or > keeping user profile data on hand when rendering a more dynamic site, > but I'd definitely love to hear about how cached data is really used > out in the field. > > Currently, three QuerySet methods, .cache(), .cache_related(), > and .cache_set() handle individual, relation, and aggregate data > caching, respectively. Each can take arguments to specify options like > expiry time. Signals are registered behind the scenes to sync the > cache, and there's also a proposal for transactional caching. Generic > relations will also benefit greatly from .cache_related(). One of my concerns I've had in the past when people have proposed this sort of work is how will object updates interact with cache consistency and correctness. The simplest example (solve this and you've solved them all, I suspect) is if the cache contains information about a Queryset qs and part of that queryset is object o1. If I update o1 in some other part of the code, what assumptions are made about qs? Possibilities are: (1) qs is invalidated from the cache and will be requeried from the database the next time it is needed (consistency + correctness) (2) qs doesn't change until it expires. The cache returns consistent results (in the sense that you can predict what will be returned if you know the state of the system), but not necessarily correct ones, because some or all of the objects in the queryset might have changed. (3) qs is updated somehow so that only necessary changes are requeried on the next access. I suspect this option doesn't scale well, but it's one possibility. Is this one of the things bouncing in your head? [...] > I'm also curious about the progress of QuerySet refactoring, which > would understandably have a huge impact on the code I'm writing. Actually I think this is going to have a lot less impact than you think. The elevator pitch for the QuerySet refactor is that is removes the SQL query consruction code from the QuerySet class and moves it all into another class (that is an attribute of QuerySet). However, all the Django-specific logic of QuerySets, including the methods like filter(), exclude(), etc, will not change. So a QuerySet class will pass off the SQL work and retrieval from the database to another class, but all user-code (including other Django code) still interacts with the QuerySet class itself, because that is responsible for things like turning SQL results back into objects or values or whatever. I would suspect you can avoid messing with the SQL construction that much (I just read through your code so far). What we can do is add a reliable __hash__ method or something similar to the Query class (the thing that does the SQL construction) so that instead of you having to replace QuerySet.iterator() and look at the query as it is constructed, you can just ask the QuerySet.query attribute what its hash is and use that to ascertain identity. I'm not sure what the comments about "working with relations" means in your iterator() implementation. Again, probably won't be hard to do that work by intercepting the QuerySet methods that are called, rather than worrying about the query construction. The good news/bad news (are you a glass half-full or glass half-empty kind of guy?) is that the QuerySet refactor is now my major project, as the unicode branch is winding down and we have to get this sucker done. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Custom field _post_create_sql()
On Sat, 2007-05-26 at 01:53 -0500, Jacob Kaplan-Moss wrote: > On 5/26/07, Justin Bronn <[EMAIL PROTECTED]> wrote: > > We encountered a similar problem on the GIS branch. Specifically, the > > OpenGIS specification requires that compliant spatial databases add > > geometry columns by calling the stored procedure AddGeometryColumn() > > after the table definition. > > > > The way we solved it was a bit different from your proposals. We > > patched the management.py function get_custom_sql_for_model() to look > > for a function on the field called "_post_create_sql." In our Field > > subclass, GeometryField, we define a _post_create_sql method that > > returns the needed SQL (a string). The field-generated SQL hitches a > > ride on the output of the initial SQL data function that is already > > called anyway. > > I'm a bit drunk right now, but I think this patch looks like a good > idea. If nobody's got any objections and if it still seems like a good > idea in the morning I'm thinking I'll apply this patch to trunk in the > morning. It seems this feature will help a lot in custom field > development. Yo, Did you think better of this, or haven't gotten around to it yet? I'm going to try and put to bed a lot of the custom field stuff that has been floating around this week (it's mostly a documentation issue; 90% of the pieces exist) and _post_create_sql() or something like it is one of the missing pieces (for custom field creation). I am wondering a little bit why this isn't _get_field_sql(), though. That could be as part of the table construction phase, so you can insert the SQL for the column directly into the CREATE TABLE statement, rather than adding it after the fact. To be clear, I'm thinking that _get_field_sq() would return something like column_name INTEGER NOT NULL and management.py would add the trailing comma if necessary but otherwise more or less include the line verbatim in the CREATE TABLE block. GIS guys, any particular reasons for the approach you took? -- laziness? economy? "it works, dammit!"? technical reason against the above? Of course, this is all peripheral to the SoC project, because I you really would need _post_create_sql() to add a constraint to a field if we didn't want to drastically change the SQL construction. So maybe it's all moot, since _post_create_sql() is probably providing a super-set of functionality of a mythical _get_field_sql() anyway. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MEDIA_URL template tag/context processor/etc again
Simon G. wrote on 04/25/07 13:33: > Evening all, > > There's been a long history of people asking for some way of easily > using the MEDIA_URL setting in templates. At a quick glance, I get > #1278, #3818, #2532, and #4105. > > These have all been marked wontfix, and I closed this last one to > match. The reasoning for the wontfix is that this leads to a slippery > slope of adding everything to the context and it's also quite easy to > implement this on your own. > > However, given the frequency of this request (I've seen it raised a > few times in django-users too), I figured I'd ask if core's still > against this, or whether we want to accept one of these. > > --Simon > +1 for #3818 I've been using a similar context processor for a while. I prefer such an approach over something like #1278 as the developer/administrator chooses which settings to expose instead of the template designer. Also it's more generic and can be reused for your own apps/settings. Just my 0.02 cheers Steven --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Generic newforms media
On 5/29/07, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> On Saturday 26 May 2007 21:55:04 Jared Kuolt wrote:
> > The javascript
> > portion seems fine, however I would see media as a class, not as a
> > method, ala a model's Meta class:
> >
> > class MyWidget(Widget):
> > ...
> > class Media:
> > js = ('/path/to/js',)
> > css = ('/path/to/css',)
>
> -1 on this alteration -- it makes things less flexible:
>
> - I might want to create MyWidget(fancy=true) which would return
> different values for media()
> - I might want to have a widget which subclasses an existing widget and
> wraps the media() method of its parent class, adding some extra values.
I had this reaction initially - but then I came to the conclusion that
extension of that type isn't really a likely use case.
A widget is ultimately a form , with some javascript/css to
help with data entry (e.g., a popup calendar). If you want slightly
different behaviour or appearance, you will need to specify different
javascript or css.
The only time inheritance would be useful is if you wanted to
remove/replace one javascript/css file from a (long) list with
another. However, as pointed out earlier in this thread, the 'lots of
little files' approach isn't conducive to good performance. For short
lists of js/css dependencies, redefining the media block would be just
as clear (if not more so), and just as efficient.
> Did I miss something about an why inner classes are more useful? In
> general they just seem more awkward to me -- they are useful in Models
> because of the way the metaclass uses them before any instances of the
> models exist.
The big reason is clarity of representation. The Widget gains a domain
specific language for specifying media requirements. This DSL is
terse, it doesn't require any additional imports, and it doesn't
require the definition of a method that returns a specific type of
data; it just becomes part of the way you specify the full
requirements of a widget.
The DSL approach also allows for input validation, in a way that is
difficult with a method. The DSL checks that the Media definition is
valid at time of Widget construction, rather than a possibly ambiguous
failure at runtime.
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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: MEDIA_URL template tag/context processor/etc again
On 5/29/07, Marc Fargas <[EMAIL PROTECTED]> wrote:
>
> Anyway, now it's clear that we should go for {{ MEDIA_URL }} which means
> that in a near future we'll have MEDIA_URL in templates, hurray! :)
Committed in [5379].
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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Can we use a django application class?
Hello,
Right now, django applications are strange creatures. They are python
packages with some magic. They have to have a "models" module.
Everything else is free form. We have strong conventions like urls.py,
maybe admin.py, but they all have to be explicitly called and used in
the project.
How about creating an actual class for django applications. This way
django applications can be actual objects instead of just being
magical python packages. We can make it a convention to put the djagno
application object in the __init__.py module of the package. We can
then use this class to add various functions related to other parts of
djagno, like defining application specific url patterns and admin
objects.
Imagine something like this:
from apps.weblog import weblog_app
INSTALLED_APPS = (weblog_app, )
from apps.weblog import weblog_app
urlpatterns = patterns('',
(r'^weblog/', weblog_app)
)
This will also be the natural place to add any future functionality
and still be backwards compatible. In contrib.admin for example, we
can easily take a look into weblog_app and see if it defines an
"admin" property or not.
It makes the application less magical because we don't have to have a
"models" module any more, it makes applications more self contained,
it adds the ability to expand application features in the future.
The __init__.py file of the application will look something like:
from . import models, admins, urls
from django.somewhere import Application
weblog_app = new Application()
weblog_app.models = models
weblog_app.admins = admins
weblog_app.urls = urls
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Can we use a django application class?
On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > Right now, django applications are strange creatures. They are python > packages with some magic. They have to have a "models" module. > Everything else is free form. We have strong conventions like urls.py, > maybe admin.py, but they all have to be explicitly called and used in > the project. Could you elaborate on what's "magical" about an application? It's just a Python module, with one convention imposed on where you put model classes so that Django can auto-discover them; adding a whole new level of infrastructure on top of that would be a serious undertaking, and I can't honestly see what it is that's so confusing or difficult about that one convention that would justify it. What real-world obstacles are being created by the requirement that models live inside the application in a module named "models"? Am I missing something here? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
I don't know a lot about the history of Django or its developers, but the impression I get is that every suggestion must answer the basic question: "what real-world problem does this solve?" In this case, I don't see a good answer to that. It's a different solution, yes, that may have some (minor) advantages, but not only do its advantages have to outweigh its disadvantages (which are many), but there has to be a compelling real-world deficiency with the current structure. Personally, I don't see such a problem. On the topic of "magic", that's a very polarizing phrase. There's no one definition of magic in the Python sense, so each person is free to define it differently. For instance, your proposal seems (in a way) more magical to me, from the perspective of average developers. Instead of supplying specific import paths to various features, you're proposing that a single import path be used for pretty much everything. You pass the same module object to urlpatterns that you pass to INSTALLED_APPS (and presumably to AdminSite in newforms-admin as well). It's not clear from a developer's perspective that each of these subframeworks is looking for something different; it seems like Django is "magically" using one object for everything. Also, what about applications that may have different URL schemes for different purposes? Your proposal limits applications to just one URL scheme, since Django would only get one application object and would have to get urlpatterns from that. If (for instance) django-registration gets integrated into django.contrib.auth, there would possibly be two separate URL structures, one for logging in/out, and one for registration. With the current system, that's easy to handle, but how would your proposal deal with that? It just seems like it'd be a lot of work for little benefit. -Gul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
Symbols? On 29 Mag, 09:47, simonbun <[EMAIL PROTECTED]> wrote: > Hmm, policy reminds me of a few pages of text with legal mumbo jumbo, > like an acceptable use policy. > > We can go for something technical, like values, properties, entries, > constraints, presets, ... or maybe it's time for something completely > different. Let's call them "tefkav"s, as in, "The Entities Formerly > Known As Values". Or something else that's actually funny. > > I'd say we wait for another couple of opinions and then let Marty > decide which one is best. In the end the name is not going to be a > show stopper for using them in a project. > > Simon > > On May 29, 8:52 am, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > On Tue, 2007-05-29 at 01:42 -0400, Max Battcher wrote: > > > On 5/28/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > > > > Maybe a combination of the two would be a bit better. "policyvalues"? > > > > Indicating its usefulness in the scope of policies while still being > > > > clear that its features only extend to the values. > > > > When I think of Policies I think more of Constraints than Values, so > > > django-policy-constraints doesn't sound that bad, just verbose. Or > > > what about just django-constraints? > > > The app doesn't *constrain* anything. It's a way to store a collection > > of values, so the any name needs to probably be under the list of > > synonyms for "value" in the thesaurus. > > > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
In all seriousness: django.contrib.bikeshed. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
James Bennett wrote: > In all seriousness: django.contrib.bikeshed. Magenta! Shall we paint it magenta? Pretty please? -- Nicola Larosa - http://www.tekNico.net/ Microsoft went berserk; tried unsuccessfully to get me fired as co-editor, and then launched a vicious, deeply personal extended attack in which they tried to destroy my career and took lethal action against a small struggling company because my wife worked there. It was a sideshow of a sideshow of the great campaign to bury Netscape and I'm sure the executives have forgotten; but I haven't. -- Tim Bray, January 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Generic newforms media
Hi all, I've just opened a ticket for Media descriptors, and uploaded a patch implementing the API that has emerged from this thread. http://code.djangoproject.com/ticket/4418 Hopefully, between this thread and the regression test, usage is obvious. Feedback is welcome. 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Volunteering for "Week in Review" postings
Thanks everyone for all your feedback, it's going to be a big help when I get started. On 5/25/07, Simon Willison <[EMAIL PROTECTED]> wrote: > ...I suggest aiming for weekly > updates even if there are only two or three things to report, but > skipping weeks entirely if nothing has haeppened. With the rate Django > is progressing at the moment I don't see that happening too often > though. I think this is probably the best approach, but I'm sure things will evolve as Django becomes more and more popular over the coming months / years. > I think the Django blog is one source of "the voice of Django" as it > were, especially to newcomers, so that's something to be careful > about. Limited snark. ;-) Oh yeah I totally agree. I've done some professional writing in my day so I'm pretty cognizant about writing to my audience ;) > As far as pushing stuff towards you for inclusion, I guess some people > may want that to be private, but I'd be happy if it was a django-users > message with a [dj-blog] subject prefix. The dj-blog prefix would be fine with me, but I'm not sure how people would take to those mixing in with their threads. May not be a big deal, though. I think a good mix would be allowing people to post a public pointer with a nod to me with the subject prefix of dj-blog or whatever and making a [EMAIL PROTECTED] email and sticking it somewhere on the blog that fwds to my personal email so people could send their comments in private if they so wish. > If we're not able to fill a short message a week with content like: > > - A summary of the SVN activity; features, bugs killed > - Any high profile/interesting blog entries > - Announcements/pronoucements I agree, I think we'll have a lot to post about. I'll talk with Adrian some more about getting things rolling! Clint http://phaedo.cx 312.863.9323 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
On 5/29/07, James Bennett <[EMAIL PROTECTED]> wrote: > > In all seriousness: django.contrib.bikeshed. > That actually made me laugh, but I think you have a valid point. This is definitely a bikeshed topic, but maybe that name can actually work. django-values provides storage and easy access to values that might need to change, a bikeshed provides storage and easy access to bikes. Plus, naming it that keeps the sense of humour that is evident around the Django community. People interested in working with any of the contrib apps will have to read the docs anyway, and we have a page that gives a short summary of each contrib app (http://www.djangoproject.com/documentation/add_ons/), so people interested in using contrib apps will know what it does anyway. +1 for django.contrib.bikeshed Jay P. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
OK, this has gone on long enough. I propose the boring-but-functional "dbsettings" -- settings stored in the db -- and unless someone can come up with a REALLY good reason not to use that, I'm going to make a dictatorial call to paint the bikeshed MY color. Objections? Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Custom field _post_create_sql()
On 5/29/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Sat, 2007-05-26 at 01:53 -0500, Jacob Kaplan-Moss wrote: > > On 5/26/07, Justin Bronn <[EMAIL PROTECTED]> wrote: > > > We encountered a similar problem on the GIS branch. Specifically, the > > > OpenGIS specification requires that compliant spatial databases add > > > geometry columns by calling the stored procedure AddGeometryColumn() > > > after the table definition. > > > > > > The way we solved it was a bit different from your proposals. We > > > patched the management.py function get_custom_sql_for_model() to look > > > for a function on the field called "_post_create_sql." In our Field > > > subclass, GeometryField, we define a _post_create_sql method that > > > returns the needed SQL (a string). The field-generated SQL hitches a > > > ride on the output of the initial SQL data function that is already > > > called anyway. > > > > I'm a bit drunk right now, but I think this patch looks like a good > > idea. If nobody's got any objections and if it still seems like a good > > idea in the morning I'm thinking I'll apply this patch to trunk in the > > morning. It seems this feature will help a lot in custom field > > development. > > Yo, > > Did you think better of this, or haven't gotten around to it yet? I hadn't heard back from Adrian yet; I want to make sure to have his OK. I'll let the GIS folks answer your question about _get_field_sql(); my impression is that PostGIS at least makes you declare GIS fields *after* you declare your table. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On May 29, 2:55 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > Could you elaborate on what's "magical" about an application? It's > just a Python module, with one convention imposed on where you put > model classes so that Django can auto-discover them; adding a whole > new level of infrastructure on top of that would be a serious > undertaking, and I can't honestly see what it is that's so confusing > or difficult about that one convention that would justify it. What > real-world obstacles are being created by the requirement that models > live inside the application in a module named "models"? > > Am I missing something here? I'm definitely not suggesting a major infrastructure change. I'm just suggesting something similar to the passing views as callable objects instead of passing them as strings containing the names of those objects. It is just more pythonic. Why are we reinventing import everywhere in django? Is this really common in python, passing strings containing package names around instead of simply passing objects? I don't see this anywhere in the library. The real world problems it would solve are the problems similar to what we had to deal with when breaking Admin out of models. How do we retain auto discovery? Remember that admin is a django application, not a core feature. Other people are likely to create similar applications and will face the same problem. I had the same problems when I wanted to add auto discovery to some other feature I wanted to build on top of Django. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Generic newforms media
On 5/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > http://code.djangoproject.com/ticket/4418 +1 from me. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
On 5/29/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I propose the boring-but-functional "dbsettings" -- settings stored in > the db -- and unless someone can come up with a REALLY good reason not > to use that, I'm going to make a dictatorial call to paint the > bikeshed MY color. Personally, I'm in favor. It immediately leads to a perfectly functional doc title, "Storing settings in the database", and it by reusing the term "settings" we can leverage what Django developers have already learned from the tutorial and basic docs. On a related note, should the Options class be renamed Settings then? I expect the individual Value classes could remain as they are, but they could instead of a -Setting suffix if that would make more sense. -Gul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > Why are we reinventing import everywhere in django? Is this really > common in python, passing strings containing package names around > instead of simply passing objects? I don't see this anywhere in the > library. I don't see this anywhere in Django, either, which makes me wonder what relevance it has ;) Seriously, it's just Python, and I don't see where we've "reinvented importing everywhere"; Django uses normal Python imports, even in the "magical" discovery of models. > The real world problems it would solve are the problems similar to > what we had to deal with when breaking Admin out of models. How do we > retain auto discovery? The inner admin class is being broken out because it doesn't belong inside a model definition. I don't see how applications as Python modules can be said to similarly "not belong" somehow... > I had the same problems > when I wanted to add auto discovery to some other feature I wanted to > build on top of Django. The same mechanisms Django uses to locate model classes are available to anyone who wants to use them, via django.db.models.loading; if you need to autodiscover models, the functions there will let you do it exactly as Django does. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > I'm definitely not suggesting a major infrastructure change. I'm just > suggesting something similar to the passing views as callable objects > instead of passing them as strings containing the names of those > objects. It is just more pythonic. > > Why are we reinventing import everywhere in django? Is this really > common in python, passing strings containing package names around > instead of simply passing objects? I don't see this anywhere in the > library. With all due respect, that's not what your proposal recommended. To just do what you're explaining now, the "proper" technique would be to supply INSTALLED_APPS with the models module of the application, since that's what's already used internally (in some places anyway) to refer to an application. Then, for urlpatterns, you'd pass in the urls module (the module itself, not just the import path), and other subframeworks would use their own locations. I wouldn't be adamantly opposed to doing it that way, though I still see little reason to deem it necessary. My main point of opposition was to your proposal's creation of some arbitrary "application" object that would encapsulate all of these different locations, so that developers used one single object to represent the various (unrelated!) aspects. I would guess (and I am definitely guessing here) that some of the logic behind the current structure is ease of implementation. By simply using import paths in strings, developers don't have to have possibly dozens of import strings just to add their applications to settings.py, only to have to repeat all those imports in urls.py. However, on a more functional note, there's the real problem of applications relying on django.conf.settings, while INSTALLED_APPS is set inside settings.py, so django.conf.settings isn't set yet, by definition. Importing an application's models module would create a circular reference that wouldn't do anybody any good. -Gul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On May 29, 3:36 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > On the topic of "magic", that's a very polarizing phrase. There's no > one definition of magic in the Python sense, so each person is free to > define it differently. For instance, your proposal seems (in a way) > more magical to me, from the perspective of average developers. > Instead of supplying specific import paths to various features, you're > proposing that a single import path be used for pretty much > everything. You pass the same module object to urlpatterns that you > pass to INSTALLED_APPS (and presumably to AdminSite in newforms-admin > as well). It's not clear from a developer's perspective that each of > these subframeworks is looking for something different; it seems like > Django is "magically" using one object for everything. > It is not going to be magical any more because you "know" you are passing this certain object that represents a Django application. When you look at the code, you will instantly know that there is this object being imported for this package and used in such and such places. But in the current situation, all you see is a couple of strings in a list called INSTALLED_APPS, but there is a lot happening behind the scene, where these strings get parsed, pieces of information being extracted from them, then they are used as python package names that must be in the python path and must contain a module called "models". > Also, what about applications that may have different URL schemes for > different purposes? Your proposal limits applications to just one URL > scheme, since Django would only get one application object and would > have to get urlpatterns from that. If (for instance) > django-registration gets integrated into django.contrib.auth, there > would possibly be two separate URL structures, one for logging in/out, > and one for registration. With the current system, that's easy to > handle, but how would your proposal deal with that? You will still be able to use urlpatterns the same way you do now. The extra advantage is that you will not have to specify the full path to the application specific urls.py file if you don't want to. This makes applications more self contained and will allow application developers to move stuff around in the application without breaking all the projects using them. Besides that, even if you use the application object, you are not limit it to one URL schema. If anything, it gives the application developers infinite flexibility without compromising current settings files. In your settings file, right after you import the Django application object you want, you can call a function on that application object and tell it what kind of URL scheme you want from it. from apps.weblog import weblog_app weblog_app.allow_registration = True # or whatever --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Custom field _post_create_sql()
On 5/29/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I hadn't heard back from Adrian yet; I want to make sure to have his OK. > > I'll let the GIS folks answer your question about _get_field_sql(); my > impression is that PostGIS at least makes you declare GIS fields > *after* you declare your table. Malcolm's _get_field_sql() question is a good one -- I'm +1 on adding that method to the fields. Only thing is, does _get_field_sql() get passed the database backend? Adrian -- Adrian Holovaty holovaty.com | djangoproject.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
Hey Ahmed -- Let's back up a step here: what's the problem you're having with the way Django currently does INSTALLED_APPS? What can't you do that you'd like to do? Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 - Object-Level Caching
> If I update o1 in some other part of the > code, what assumptions are made about qs? Hmm, yeah... I haven't focused enough attention on .cache_set() yet, heheh. I was definitely just going to implement (1) first, and then worry about something more advanced once I got to the "smart" functionality (which I might just be making default behaviour now). At some point I'll be writing a class with which cached queries register so that pre/post_save signals can freshen the cache; that's should lightweight enough to scale by itself, but to implement (3) I guess it'd also have to track which PKs are present. I'm not really sure if (2) is desirable. > What we can do is add a > reliable __hash__ method or something similar to the Query class (the > thing that does the SQL construction) so that instead of you having to > replace QuerySet.iterator() and look at the query as it is constructed, > you can just ask the QuerySet.query attribute what its hash is and use > that to ascertain identity. Sounds great. I was wondering if there was some way to automatically generate cache keys for .cache_set() as well. Perhaps this could tie in quite nicely. Also, the approach I'm taking currently with the overriden QuerySet worries me because I think it only really works right now if .cache*() is the last method on the chain. > The good news/bad news (are you a glass half-full or glass half-empty > kind of guy?) is that the QuerySet refactor is now my major project, as > the unicode branch is winding down and we have to get this sucker done. It sounds good to me! I've had a good experience migrating to new Django features in the past (thank you newforms!) and this sounds like it's definitely the way to go. I'm just wondering now if I should maintain two versions of the project... guess I'll have to see once it rolls around. Thanks for the comments! Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On May 29, 7:12 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > > > Why are we reinventing import everywhere in django? Is this really > > common in python, passing strings containing package names around > > instead of simply passing objects? I don't see this anywhere in the > > library. > > I don't see this anywhere in Django, either, which makes me wonder > what relevance it has ;) The settings.py file is full of strings defining things that will eventually be imported using __module__ instead of a simple, well known and obvious import. > Seriously, it's just Python, and I don't see where we've "reinvented > importing everywhere"; Django uses normal Python imports, even in the > "magical" discovery of models. I know that it uses python imports. It is always python. Even before magic-removal, it was all python, right? And I'm not suggesting to drop everything we have now. I'm suggesting that it would be more transparent and obvious if the user can look and see that the weblog_app he imported with an explicit import is put in INSTALLED_APPS. It is similarly more obvious in urls.py for a user to see that the weblog_app which he imported with an explicit import is going to handle all urls that start with 'weblog'. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On 2007-05-29 05:43:08 -0600, Ahmad Alhashemi
<[EMAIL PROTECTED]> said:
>
> Hello,
>
> Right now, django applications are strange creatures. They are python
> packages with some magic. They have to have a "models" module.
> Everything else is free form. We have strong conventions like urls.py,
> maybe admin.py, but they all have to be explicitly called and used in
> the project.
>
> How about creating an actual class for django applications. This way
> django applications can be actual objects instead of just being
> magical python packages. We can make it a convention to put the djagno
> application object in the __init__.py module of the package. We can
> then use this class to add various functions related to other parts of
> djagno, like defining application specific url patterns and admin
> objects.
>
> Imagine something like this:
> from apps.weblog import weblog_app
> INSTALLED_APPS = (weblog_app, )
>
> from apps.weblog import weblog_app
> urlpatterns = patterns('',
>(r'^weblog/', weblog_app)
> )
>
> This will also be the natural place to add any future functionality
> and still be backwards compatible. In contrib.admin for example, we
> can easily take a look into weblog_app and see if it defines an
> "admin" property or not.
>
> It makes the application less magical because we don't have to have a
> "models" module any more, it makes applications more self contained,
> it adds the ability to expand application features in the future.
>
> The __init__.py file of the application will look something like:
> from . import models, admins, urls
> from django.somewhere import Application
> weblog_app = new Application()
> weblog_app.models = models
> weblog_app.admins = admins
> weblog_app.urls = urls
>
>
>
I like this idea, but really doesn't solve much in the common case. It
provides for more modularity of an app and offers the ability to make
things feel even more Pythonic. However, most things can be solved by
using custom settings in settings.py and just knowing how to make a
module work right.
One thing this makes me think of is allowing custom display names for
applications. Currently there is no way to mark application names for
translation (that I know of). This is a solution that can work in a
more modular way than making INSTALLED_APPS a dictionary for example.
--
Brian Rosner
http://www.brosner.com/blog
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Can we use a django application class?
On May 29, 7:16 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > > > I'm definitely not suggesting a major infrastructure change. I'm just > > suggesting something similar to the passing views as callable objects > > instead of passing them as strings containing the names of those > > objects. It is just more pythonic. > > With all due respect, that's not what your proposal recommended. To > just do what you're explaining now, the "proper" technique would be to > supply INSTALLED_APPS with the models module of the application, since > that's what's already used internally (in some places anyway) to refer > to an application. Then, for urlpatterns, you'd pass in the urls > module (the module itself, not just the import path), and other > subframeworks would use their own locations. Well, it is called INSTALLED_APPS, not MODELS_OF_INSTALLED_APPS, right? :) The only reason that the "models module of the application is what's already used internally (in some places anyway) to refer to an application" is because we don't have an application object. And that's exactly what I'm proposing. In the URL's, it'll be like saying: delegate weblog/* to the weblog app. It is not a replacement for what is already in here. It just makes project files a bit simpler easier and shift things into applications. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On 5/29/07, Brian Rosner <[EMAIL PROTECTED]> wrote: > One thing this makes me think of is allowing custom display names for > applications. Currently there is no way to mark application names for > translation (that I know of). This is a solution that can work in a > more modular way than making INSTALLED_APPS a dictionary for example. Not that it impacts any of the arguments here, but check out ticket #3591 for a proposed solution. -Gul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Custom field _post_create_sql()
On 5/29/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Malcolm's _get_field_sql() question is a good one -- I'm +1 on adding > that method to the fields. Only thing is, does _get_field_sql() get > passed the database backend? If the method is going in, I think passing in the db backend would be a great idea along with pushing django.db.backends.X.creation into the specific field classes. Joseph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 - Object-Level Caching
On 2007-05-29 01:37:50 -0600, Paul Collier <[EMAIL PROTECTED]> said: > > Hello all! > > Continuing with the string of posts regarding this year's GSoC, I'm > pleased to be working on new caching functionality for Django's ORM > under the mentorship of Gary Wilson[1]! Big thanks to him and all the > people from the community who made this possible. Now I've just got to > hold up my end of the bargain ;) > > An updated version of my original proposal is available on Django's > wiki[2] and the project repository is available from Google Project > Hosting[3]. > > This project aims to condense common caching idioms into simple > QuerySet methods that deal with cached data intelligently, refill > expired cache, track instance modification/deletion, descend through > relationships, and so on. I've tried to make it accommodate the most > common use cases, be it dumping front-page news articles to cache or > keeping user profile data on hand when rendering a more dynamic site, > but I'd definitely love to hear about how cached data is really used > out in the field. > > Currently, three QuerySet methods, .cache(), .cache_related(), > and .cache_set() handle individual, relation, and aggregate data > caching, respectively. Each can take arguments to specify options like > expiry time. Signals are registered behind the scenes to sync the > cache, and there's also a proposal for transactional caching. Generic > relations will also benefit greatly from .cache_related(). > > More detail is available on the wiki page, but lots of the little > issues that surround the implementation are still bouncing around in > my head; the page is going to be expanding and mutating throughout the > next few months, I'm sure. The timeline is a little underdeveloped, > for one. Comments and criticisms are always welcome! > > The project itself is currently a single module which has a class > derived from QuerySet with all of the new functionality, and a little > hack to inject the .cache(), etc methods right back into QuerySet. It > also ships with a project in which I'll be writing proper tests. Some > sort of miniature cache-testing framework may be in order too. > Eventually, perhaps it'll become fit for inclusion in the Django > proper--but either way it doesn't require a huge amount of core > modification. > > I'm also curious about the progress of QuerySet refactoring, which > would understandably have a huge impact on the code I'm writing. > Either way, this new code applies directly to a Django project I've > been working on for the last while, so I have the motivation to > maintain this project wherever it may go! > > Thanks, > Paul Collier > > [1] http://gdub.wordpress.com/ > [2] http://code.djangoproject.com/wiki/ObjectLevelCaching > [3] http://code.google.com/p/django-object-level-caching/ > > > It looks like you are working some really neat stuff Paul! I came across ticket #17 last week and thought it was an interesting ticket and started through some prototyping. It seemed to be in my prototyping that the project you are working on sort of overlapped some of my ideas. It appears to actually be two different things, but kind of not. #17 looks like it tries to solve having multiple instances of the same object in memory. When thinking about implementing this it starts to work itself in to the QuerySet and how it would select an object since it would need to look into memory first then the database. I guess what I am trying to get at is how does your project and ticket #17 corrolate, or better yet, is this something you thought of. Your project seems to be when objects need to be cached over several requests which could mean multiple instances of Django in memory at different times. -- Brian Rosner http://www.brosner.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > Well, it is called INSTALLED_APPS, not MODELS_OF_INSTALLED_APPS, > right? :) > > The only reason that the "models module of the application is what's > already used internally (in some places anyway) to refer to an > application" is because we don't have an application object. And > that's exactly what I'm proposing. Point of fact: Python already exposes a module for each application, so its supposed non-existance is hardly the "only reason" it's done the way it is. It uses the models module instead, because that's where the useful information is stored. However, this is already well its way down a path that will accomplish nothing, so I'll take Jacob's advice and just step back from this one for a bit until it's clear what the real need is. -Gul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On May 29, 5:24 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Hey Ahmed --
>
> Let's back up a step here: what's the problem you're having with the
> way Django currently does INSTALLED_APPS? What can't you do that you'd
> like to do?
One example is provided by the admin interface: Model classes are
displayed grouped by the application they're defined in. The apps have
labels which are e.g. used to prefix database table names. There's no
way in current SVN to disambiguate two third-party apps with the same
label - e.g. if I have two third-party apps defined in
'a.b.c.hierarchy' and 'c.d.e.hierarchy' (using 'hierarchy' just as an
example module which might meaningfully exist in otherwise unrelated
apps), then both apps get labels of 'hierarchy' and database tables
with names prefixed with 'hierarchy_' - a recipe for clashing names
which cannot be resolved without making source code changes to at
least one of the apps. There is also no way to specify an
internationalised or more descriptive name for an app in the admin
view (adminapplist).
Clearly apps are an abstraction which exist in that we all know what
we mean when we say "Django app", but there's nowhere to hang
conceptual items which go along with that abstraction, like
"descriptive name in my language".
I added a patch to ticket #3591 which resolves the needs I referred to
above (user-definable app label, internationalized descriptive name)
through the use of a very light-weight app class (basically just an
attribute holder for the app label and descriptive name) and allowing
definitions in INSTALLED_APPS such as
from django.conf import app
INSTALLED_APPS = {
...
'django.contrib.admin',
app('django.contrib.auth', verbose_name='Authorization/
Authentication'),
}
The patch, when applied, works fine with all unit tests and
furthermore, browsing the admin and databrowse applications works as
expected (these sites use the app label when generating some of their
URLs).
The patch is waiting for some core developer attention; Malcolm
Tredinnick has had an initial look but not arrived at a decision yet.
(It's quite a big patch in terms of the different places it touches,
but hopefully fairly easy to follow). Malcolm invited users to try out
the patch but we have only had one user who has given feedback (quite
positive, in that case - "it just works").
My changes don't address all of the things Ahmed was after, but the
question about the need for an app class (albeit lightweight) is a
valid one, and I've scratched my itch with the patch:
http://code.djangoproject.com/attachment/ticket/3591/app_labels.6.diff
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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Can we use a django application class?
On May 29, 7:24 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Hey Ahmed -- > > Let's back up a step here: what's the problem you're having with the > way Django currently does INSTALLED_APPS? What can't you do that you'd > like to do? > > Jacob I can't change my application structure without changing setting files of projects. I can't extend Django applications with extra features that require auto-discovery. I'm working on a CMS using Python, and I want to know which applications support special features that my CMS can build upon (something similar to admin). I can't install two applications with the same name. I can't translate my application names (thank you Brian). The most important thing is that it makes things more pythonic. This is important. This is why magic-removal was undertaken, isn't it? To paraphrase what Brian said, it might not appear that ugly in the common case, but I'm sure that you will find solutions to all the problems I've mentioned above. But those solutions are going to look really ugly and hackish in my opinion. For example, why do I have to use project wide settings to tell two closely related applications how to deal with each other? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On May 29, 6:06 pm, Vinay Sajip <[EMAIL PROTECTED]> wrote: > My changes don't address all of the things Ahmed was after, but the > question about the need for an app class (albeit lightweight) is a > valid one, and I've scratched my itch with the patch: > > http://code.djangoproject.com/attachment/ticket/3591/app_labels.6.diff > Sorry for the type, that should be "Ahmad". Regards, Vinay --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On May 29, 7:53 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > > > Well, it is called INSTALLED_APPS, not MODELS_OF_INSTALLED_APPS, > > right? :) > > > The only reason that the "models module of the application is what's > > already used internally (in some places anyway) to refer to an > > application" is because we don't have an application object. And > > that's exactly what I'm proposing. > > Point of fact: Python already exposes a module for each application, > so its supposed non-existance is hardly the "only reason" it's done > the way it is. It uses the models module instead, because that's where > the useful information is stored. Models are completely irrelevant to any web application that do not use databases. These include online conversion tools, mashups that get all their information from other services over the web, and a MySQL administration tool like phpMyAdmin. All real projects and I personally intend to implement in Django. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > I can't extend Django applications with extra features that require > auto-discovery. I'm working on a CMS using Python, and I want to know > which applications support special features that my CMS can build upon > (something similar to admin). Sure you can. Again, look in django.db.models.loading, or just iterate on INSTALLED_APPS and import stuff yourself. It's not that hard. > I can't install two applications with the same name. As far as I know, you can install two applications which live in folders which happen to have the same name though they're nested inside different parts of an overall directory structure (e.g., you can have 'a.b.c.foo' and 'd.e.f.foo'); it's just a matter of setting 'app_label' manually since Django infers that from the directory name. Two applications whose Python paths are identical, of course, represent an impossible situation, but this is impossible because of Python. > I can't translate my application names (thank you Brian). If that's the only justification left, I'd say we should just find a good way to mark app names for translation, not overhaul the way applications are put together. > The most important thing is that it makes things more pythonic. This > is important. This is why magic-removal was undertaken, isn't it? More Pythonic in what way? And to whom? To me, a Python module is about the most "Pythonic" way to wrap something up, and isn't "magical" at all -- subjectively, having a specialized class to represent something that can be represented by a Python module is the "un-Pythonic" approach. But there's the problem: we're down to an entirely subjective distinction. > really ugly and hackish in my opinion. For example, why do I have to > use project wide settings to tell two closely related applications how > to deal with each other? Why do you have to do that? If they're that closely related, why can't they know about each other directly? Why can't one app export some constants for the other to refer to? I think you're confusing "this is how some people do things in Django" with "this is how you must do things in Django"... -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On May 29, 7:12 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > > As far as I know, you can install two applications which live in > folders which happen to have the same name though they're nested > inside different parts of an overall directory structure (e.g., you > can have 'a.b.c.foo' and 'd.e.f.foo'); it's just a matter of setting > 'app_label' manually since Django infers that from the directory name. But to do that, you have to set Meta.app_label in *every* model of an application (otherwise, different models are not recognised as being part of the same application - so e.g. foreign key relationships break). This surely violates DRY. > Two applications whose Python paths are identical, of course, > represent an impossible situation, but this is impossible because of > Python. > > > I can't translate my application names (thank you Brian). > > If that's the only justification left, I'd say we should just find a > good way to mark app names for translation, not overhaul the way > applications are put together. As I mentioned in another post on this thread, the patch in ticket #3591 passes all unit tests and does this in a minimalist way - not really much of an "overhaul". > > The most important thing is that it makes things more pythonic. This > > is important. This is why magic-removal was undertaken, isn't it? > > More Pythonic in what way? And to whom? To me, a Python module is > about the most "Pythonic" way to wrap something up, and isn't > "magical" at all -- subjectively, having a specialized class to > represent something that can be represented by a Python module is the > "un-Pythonic" approach. > > But there's the problem: we're down to an entirely subjective distinction. > > > really ugly and hackish in my opinion. For example, why do I have to > > use project wide settings to tell two closely related applications how > > to deal with each other? > > Why do you have to do that? If they're that closely related, why can't > they know about each other directly? Why can't one app export some > constants for the other to refer to? I think you're confusing "this is > how some people do things in Django" with "this is how you must do > things in Django"... IMO the dispatcher mechanism allows apps to interact with each other in an extensible way. While misuse of this might lead to performance problems, the dispatcher could easily be used to e.g. advertise "services" provided by apps, or certain "affinities" that they have (you get to decide what "services"/"affinities" means) - it is, after all, a generalised publish/subscribe mechanism with very loose coupling. 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Generic newforms media
On Tuesday 29 May 2007 11:26:45 Russell Keith-Magee wrote:
> On 5/29/07, Luke Plant <[EMAIL PROTECTED]> wrote:
> > On Saturday 26 May 2007 21:55:04 Jared Kuolt wrote:
> > > The javascript
> > > portion seems fine, however I would see media as a class, not as
> > > a method, ala a model's Meta class:
> > >
> > > class MyWidget(Widget):
> > > ...
> > > class Media:
> > > js = ('/path/to/js',)
> > > css = ('/path/to/css',)
> >
> > -1 on this alteration -- it makes things less flexible:
> >
> > - I might want to create MyWidget(fancy=true) which would return
> > different values for media()
> > - I might want to have a widget which subclasses an existing widget
> > and wraps the media() method of its parent class, adding some extra
> > values.
>
> I had this reaction initially - but then I came to the conclusion
> that extension of that type isn't really a likely use case.
>
> A widget is ultimately a form , with some javascript/css to
> help with data entry (e.g., a popup calendar). If you want slightly
> different behaviour or appearance, you will need to specify different
> javascript or css.
>
> The only time inheritance would be useful is if you wanted to
> remove/replace one javascript/css file from a (long) list with
> another. However, as pointed out earlier in this thread, the 'lots of
> little files' approach isn't conducive to good performance. For short
> lists of js/css dependencies, redefining the media block would be
> just as clear (if not more so), and just as efficient.
Hmm, I'm worrying about the case when the author of the parent widget
decides there is an extra dependency and adds it in. The subclass now
is missing a file -- this is the classic scenario that inheritance
prevents. Because of this, the size of the list of dependencies seems
irrelevant to me.
I don't think the subclassing scenario which adds/replaces a file is
that unlikely a use case. There may be perfectly good reasons to do so
e.g. adding some scriptaculous-type library that you don't want to load
every time, nor include in your own javascript files. Of course, there
are still ways to do it using the inner class, but if you add in the
theme scenario, where you potentially want each instance of the widget
to have different dependencies, and to decide them at runtime (e.g.
based on user's prefs, base URL of request etc) then you have bigger
problems.
If we are saying that the 'lots of little files' approach is a bad idea
that we don't need to be concerned about, why are we even adding this
feature? The ideal situation is that we analyse all the dependencies
in advance, create one CSS file and one JS file to cope with them, and
just include those. It seems strange to be adding a method that is
supposed to give flexibility and then arbitrarily limit each widget so
that they cannot vary on a per instance basis.
Another use case: suppose the subclass widget needs some javascript,
fancywidgets.js. It reads its parents dependencies, finds calendar.js,
and replaces it with fancywidgets_plus_calendar.js, reducing a
performance problem (OK, contrived, but could be useful in some
circumstances).
Again: think localisation -- media() could respond to the language
settings of the user/request, which could affect both CSS and
javascript (I'm out of touch with the current Django way of doing
things in this area, so it might not be an issue, but we should
remember that people might not want to do things 'the Django way').
I've had to add hacks in before to get around the inflexibility of inner
classes. In those cases, there was good reason for those inner
classes -- Django needs to be able to get at the data they contained
before any instances of the outer class existed. I can't see the
corresponding reasons here, and I'm not at all convinced that the
neatness of representation of a DSL outweighs the functionality
disadvantages.
Luke
--
"If your parents never had children, the chances are you won't either."
Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Generic newforms media
On Tuesday 29 May 2007 21:13:44 Luke Plant wrote: > I've had to add hacks in before to get around the inflexibility of > inner classes. It looks like my hack for this will no longer be needed in newforms-admin. That's because: class MyModel: ... class Admin: fields = has turned into: class ModelAdmin: def fieldsets(): ... I think that's a pretty powerful argument. Regards, Luke -- "If your parents never had children, the chances are you won't either." Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On May 29, 9:12 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > > > I can't extend Django applications with extra features that require > > auto-discovery. I'm working on a CMS using Python, and I want to know > > which applications support special features that my CMS can build upon > > (something similar to admin). > > Sure you can. Again, look in django.db.models.loading, or just iterate > on INSTALLED_APPS and import stuff yourself. It's not that hard. Is this considered part of the stable API? Is it part of the backward compatibility guarantee? I can do it myself, and everyone do the same themselves, then the internals change and all our code needs re-writing. Or we can do it once with a nice API and everyone can grow safely inside the django application object. > > I can't install two applications with the same name. > > As far as I know, you can install two applications which live in > folders which happen to have the same name though they're nested > inside different parts of an overall directory structure (e.g., you > can have 'a.b.c.foo' and 'd.e.f.foo'); it's just a matter of setting > 'app_label' manually since Django infers that from the directory name. The solution is ugly, as I've pointed out before. Vinay already mentioned this. > Two applications whose Python paths are identical, of course, > represent an impossible situation, but this is impossible because of > Python. I never said anything about that! > > I can't translate my application names (thank you Brian). > > If that's the only justification left, I'd say we should just find a > good way to mark app names for translation, not overhaul the way > applications are put together. No sir, this is but one problem. The other problems still don't have easy, API like, pythonic solutions. Not to mention that you've skipped my first point: I can't change my application structure without changing setting files of projects. > > The most important thing is that it makes things more pythonic. This > > is important. This is why magic-removal was undertaken, isn't it? > > More Pythonic in what way? And to whom? To me, a Python module is > about the most "Pythonic" way to wrap something up, and isn't > "magical" at all -- subjectively, having a specialized class to > represent something that can be represented by a Python module is the > "un-Pythonic" approach. > > But there's the problem: we're down to an entirely subjective distinction. I had very strong feeling regarding this, and I thought everyone would share them, so I guess that's my mistake. Maybe we need an outside opinion, like from one of Python's mailing lists. Show two approaches and ask them which one looks more "pythonic" to them. > > really ugly and hackish in my opinion. For example, why do I have to > > use project wide settings to tell two closely related applications how > > to deal with each other? > > Why do you have to do that? If they're that closely related, why can't > they know about each other directly? Why can't one app export some > constants for the other to refer to? Because sometimes you want to use one of them alone. > I think you're confusing "this is > how some people do things in Django" with "this is how you must do > things in Django"... Sorry I didn't understand your last comment. Please bare with an English as a second language speaker :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > Is this considered part of the stable API? Is it part of the backward > compatibility guarantee? I can't make a hard and fast promise, but since there are quite a few bits of Django itself which rely on this API and would have to be rewritten if it changed, you should be safe relying on it. > The solution is ugly, as I've pointed out before. Vinay already > mentioned this. And there are a couple proposals floating around for how to make app_label not ugly; none of which require an explicit class for applications :) > No sir, this is but one problem. The other problems still don't have > easy, API like, pythonic solutions. Not to mention that you've skipped > my first point: > > I can't change my application structure without changing setting files > of projects. Huh? I guess I don't really understand this, so I'll walk through a couple examples: 1. Suppose you decide that instead of an application-specific URLConf named 'urls.py', you want to have 'my_urls.py', and in the process you change a number of the URL mappings in your application. Making your project aware of this change does not require changes to your settings file (it only requires a change to the root URLConf file of the project, probably just a different argument to 'include' -- the ROOT_URLCONF setting itself stays the same). 2. Suppose you want to go from having a 'views.py' file to having a module 'my_views' with multiple view files inside it. Making your project aware of this change does not require changes to your settings file (it just requires a change inside the application's URLConf to reflect the new Python paths to the views). 3. Suppose you find that several of your view functions have repetitive logic, and decide to replace them with a single consolidated function which takes parameters, or with a generic view. Again, this does not require changes to your settings file (once more, a change in the app's URLConf will handle it). Unless the application changes in such a way as to require the presence of a setting which was not required before, the settings file shouldn't need to be touched in the process of refactoring/restructuring application code. > I had very strong feeling regarding this, and I thought everyone would > share them, so I guess that's my mistake. Maybe we need an outside > opinion, like from one of Python's mailing lists. Show two approaches > and ask them which one looks more "pythonic" to them. For what it's worth, Guido seems to like Django (for certain values of "like" and "Django"). Does that count? ;) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
Also, you might want to have a look at the WSGI ecosystem and specifically Paste Deploy, which can kind-of be made to work with Django and does a lot of what you seem to want, but in a framework-neutral way. Anyway, I think we're just talking past each other at this point, so I'll bow out. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Backwards incompatibility between 0.91 and 0.95 (mutli-auth sessions)
In [3226], the multi-auth branch landed. It introduced a backwards incompatibility in existing sessions, which are used for session-based auth. The code responsible for supplying request.user prior to that rev was e.g. handlers.modpython.ModPythonRequest._get_user. After that rev, it's contrib.auth.get_user. Prior to that rev, a valid user was returned if session['_auth_user_id'] existed and had a contrib.auth.models.User with that PK. After that rev, session['_auth_user_backend'] is required as well. If a KeyError is raised from either '_auth_user_id' or (in the new rev) '_auth_user_backend', AnonymousUser is returned instead. This means that any existing auth'd sessions are treated as anonymous after this change. As a workaround, the attached diff heals the backend if _auth_user_id exists but _auth_user_backend doesn't by assuming that it should be 'django.contrib.auth.backends.ModelBackend'. This allows old sessions to be migrated to the new auth keys without requiring users to log in again and also avoids to crashes where code assumes that the user returned from contrib.auth.get_user has a backend attribute (which AnonymousUser does not). Use that patch with caution-- if you plan on using some other backend for auth, the patch could be a security concern. -Jeremy --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~--- Index: texasgigs.com/trunk/vendor/django_dist/django/contrib/auth/__init__.py === --- texasgigs.com/trunk/vendor/django_dist/django/contrib/auth/__init__.py (revision 1052) +++ texasgigs.com/trunk/vendor/django_dist/django/contrib/auth/__init__.py (revision 1053) @@ -82,5 +82,11 @@ try: user_id = request.session[SESSION_KEY] -backend_path = request.session[BACKEND_SESSION_KEY] +try: +backend_path = request.session[BACKEND_SESSION_KEY] +except KeyError: +#heal auth'd sessions which are missing the backend. +# (an undocumented backwards-incompatibility with Django 0.91). +backend_path = 'django.contrib.auth.backends.ModelBackend' +request.session[BACKEND_SESSION_KEY] = backend_path backend = load_backend(backend_path) user = backend.get_user(user_id) or AnonymousUser()
Re: Custom field _post_create_sql()
Malcolm Tredinnick wrote:
> GIS guys, any particular reasons for the approach you took? -- laziness?
> economy? "it works, dammit!"? technical reason against the above?
>
In PostGIS, the AddGeometryColumn() function needs to be run separately
after the create table. It adds the geometry field to the table, adds
its definition (projection, geometry type, dimensions) to the
'geometry_columns' table, creates a number of constraints, etc.
Normal process for setting up a geometry table:
CREATE TABLE "mytable" (... every field /except/ geometry ones ...);
SELECT AddGeometryColumn("mytable", "mygeometryfield", 4326, "POLYGON", 2);
CREATE INDEX "mytable_mygeometryfield" ON "mytable" USING GIST
("mygeometryfield" GIST_GEOMETRY_OPS);
Thats why it needed to be post_create. post_create allows you to "fix"
anything you didn't like in a create as well or add special indexes or
constraints.
Not saying adding goodies to CREATE TABLE is bad, just that it doesn't
work everywhere.
Rob :)
--
One Track Mind Ltd.
PO Box 1604, Shortland St, Auckland, New Zealand
Phone +64-9-966 0433 Mobile +64-21-572 632
Web http://www.onetrackmind.co.nz
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Generic newforms media
On 5/30/07, Luke Plant <[EMAIL PROTECTED]> wrote: > > On Tuesday 29 May 2007 21:13:44 Luke Plant wrote: > > > I've had to add hacks in before to get around the inflexibility of > > inner classes. > > It looks like my hack for this will no longer be needed in > newforms-admin. That's because: > > class MyModel: > ... > class Admin: > fields = > > has turned into: > > class ModelAdmin: > def fieldsets(): > ... > > I think that's a pretty powerful argument. The reason for that change was to get Admin options out of the Model. Ultimately, the goal is to have Models be purely definitions of data. The Admin inner class was standing in the way of that. 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
On May 30, 12:56 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > OK, this has gone on long enough. > > I propose the boring-but-functional "dbsettings" -- settings stored in > the db -- and unless someone can come up with a REALLY good reason not > to use that, I'm going to make a dictatorial call to paint the > bikeshed MY color. > > Objections? > > Jacob I was going to suggest "livesettings", but "dbsettings" is 2 letters shorter. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Custom field _post_create_sql()
On Tue, 2007-05-29 at 11:47 -0500, Joseph Kocherhans wrote: > On 5/29/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > > Malcolm's _get_field_sql() question is a good one -- I'm +1 on adding > > that method to the fields. Only thing is, does _get_field_sql() get > > passed the database backend? > > If the method is going in, I think passing in the db backend would be > a great idea along with pushing django.db.backends.X.creation into the > specific field classes. I'm +1 on passing in the database backend. I'm probably -1 on putting *all* of the creation stuff into field classes, though. The current method, which is like, means that fields do not have to worry about the database, by and large. Only in the case of custom fields with very special creation requirements does the leakage have to happen. I may not have explained this very well, but it smells a little bad to me (deep technical reason, I realise, but without a whiteboard and the ability to wave my arms a bit, it's hard to explain in 250 words or less). There are going to be other opinions, though. One "pie-in-the-sky" reason for my preferring the current way is that it makes replacing the database layer (e.g. SQL Alchemy, rdflib, Fred's Own Fantastic Storage System(tm), ...) cleaner, since there isn't SQL-specific stuff in the Field classes, mostly. I've spent some time over the months wondering how we could add creation for specialised fields without encroaching on the field classes, but I'm not sure it's particularly neat to try and do so. Given the GIS guys' requirements (post-creation modification is necessary), which is also probably the easiest way to add constraints, I guess there's an argument for both _get_field_sql() and _post_create_sql() hooks in there. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 - Object-Level Caching
On Tue, 2007-05-29 at 16:26 +, Paul Collier wrote: > > If I update o1 in some other part of the > > code, what assumptions are made about qs? > Hmm, yeah... I haven't focused enough attention on .cache_set() yet, > heheh. I was definitely just going to implement (1) first, and then > worry about something more advanced once I got to the "smart" > functionality (which I might just be making default behaviour now). At > some point I'll be writing a class with which cached queries register > so that pre/post_save signals can freshen the cache; that's should > lightweight enough to scale by itself, but to implement (3) I guess > it'd also have to track which PKs are present. I'm not really sure if > (2) is desirable. I think your first option has the same problem that you spotted in number (3). Here's the possibly hidden problem with (1) -- which was "if o1 changes, invalidate all querysets that are cached containing o1" -- every time an object is saved, you have to work which cached querysets contain that object. This would be something like O(n*avg_size_querysets) if you don't come up with a fancy hash or bitmap or something to work out which are the dirty querysets. Not a bad first implementation, but check that it scales (I suspect the naïve approach will struggle to do so). I wouldn't worry about solving this up front, since it's a localised thing that you can tweak later once the bulk of the functionality is there, but it sounds like a fun problem to think about. Cheers, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can we use a django application class?
On Tue, 2007-05-29 at 11:50 -0700, Vinay Sajip wrote: > > On May 29, 7:12 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > > On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > > > > As far as I know, you can install two applications which live in > > folders which happen to have the same name though they're nested > > inside different parts of an overall directory structure (e.g., you > > can have 'a.b.c.foo' and 'd.e.f.foo'); it's just a matter of setting > > 'app_label' manually since Django infers that from the directory name. > > But to do that, you have to set Meta.app_label in *every* model of an > application (otherwise, different models are not recognised as being > part of the same application - so e.g. foreign key relationships > break). This surely violates DRY. Or fix the far smaller problem of making app_label inherit down from the app directory. Don't use a tank to kill an ant here; this isn't a justification for giving up the fairly natural directory structure we currently have. I'm kind of amazed this thread has any legs at all. It's only a different way of doing things without being clearly better and storing things in directories is a pretty natural layout. Arguing that replacing the models.py single requirement with a much larger interface requirement seems to be missing the forest for the trees. I'm -1 so far. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Custom field _post_create_sql()
> In PostGIS, the AddGeometryColumn() function needs to be run separately > after the create table. It adds the geometry field to the table, adds > its definition (projection, geometry type, dimensions) to the > 'geometry_columns' table, creates a number of constraints, etc. Thanks, Rob, for the excellent summary; below, I'll give a bit more detail. > GIS guys, any particular reasons for the approach you took? -- laziness? > economy? "it works, dammit!"? technical reason against the above? Malcolm, the fact that AddGeometryColumn() must be called _after_ the CREATE TABLE statement is not a choice of the GIS branch. As I stated before, geometry column creation with the AddGeometryColumn() stored procedure is part of the OpenGIS standard. [1] When figuring out where to place the check for the _post_create_sql() function, I did not randomly choose a function in management.py. My goals were to (1) accomplish geometry column creation in the aforementioned manner, (2) minimize patches outside of the contrib directory, and (3) use the existing API to the fullest extent possible. I believe this solution, a three-line patch to an existing post-initialization SQL function, satisfies these criteria. -Justin [1] See Open GIS Consortium, Inc., OpenGIS Simple Feature Specification For SQL Rev. 1.1, Document 99-049 (May 5, 1999), at 2-38 (s. 2.3.8, Geometry Values and Spatial Reference Systems, pg. 40), available at http://www.opengis.org/docs/99-049.pdf. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Patch for cookie-based mod_python/apache authentication
In http://code.djangoproject.com/ticket/3583 I've added a patch which refactors the existing mod_python authentication function and adds a new cookie based one. If anyone can, a review would be good. Specifically: 1. Does it work correctly for you? (it does for me) 2. Is the change in patch 2 a smart idea? 3. Is there anything I'm missing? The only step better than this would be a full PythonHandler which would return a redirect response to a log in page (specified by a PythonOption?) if the user isn't authenticated or doesn't have the correct permissions, otherwise it can just return apache.DECLINED, since the mod_python docs say: Where that final status is apache.DECLINED, Apache will fall back to using the default-handler and attempt to serve up the target as a static file. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
