Re: 1.2 Proposal: Extra template tags and filters
On Tue, Aug 11, 2009 at 11:20 PM, Andrew Gwozdziewycz wrote: > > On Tue, Aug 11, 2009 at 10:50 AM, Richard > Davies wrote: >> > I'm a fan of having more if tags, but am not a fan of having if tags that > require me to remember all of the suffixes. Perhaps a smarter if tag in > general would be better... A smarter "if" tag has already been proposed as a v1.2 feature, and I think there is some support for it. However, "smarter" doesn't mean "exposing everything that Python can do" - it just means clarifying the syntax for some of the simple cases. ==, < >, and "in" are possible candidates. "startswith" sounds a bit too much like "logic in the template" feature creep to me. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App Engine support
On Wed, Aug 12, 2009 at 2:56 AM, mitch wrote: > > As a heavy SimpleDB user, I would love to see a way to use Django and > SimpleDB together and I would certainly be willing to devote time to > helping make that happen. I think I can contribute on the SimpleDB > side (boto has supported SimpleDB for over a year and I'm very > familiar with the service) but every time I sit down to try to figure > out how to begin the process of integrating it into Django, I get > stuck. I've only used Django a few times and I'm really not familiar > with the internals but it didn't seem obvious to me how or where to > get started. Begin at the beginning :-) Pick a small task - e.g., converting a simple Django ORM query into SimpleDB's query API, and see where that takes you. Rinse and repeat until you have a working API. > Is the consensus that further refactoring or rethinking of things like > QuerySet and Query are required to make this happen? Not really a consensus - more a general feeling that there are some SQL-specifics that still need to be purged. The Query/QuerySet interface was designed with support for non-SQL backends as a design goal, but without an actual non-SQL backend implementation to prove the design. Finding and purging these SQL-specific components is the work in progress. > Is there an > "official" interface between Django and DB backends? It's official in the sense that exists in the core codebase. However, unlike most of Django's official interfaces, it is not extensively documented. The two interfaces are sql.Query and db.backend. If you're interested in this problem, you're going to need to go spelunking through the code, trying to understand it from the SQL point of view, and then adapting it for a non-SQL backend. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal for contrib feature (DictionaryField in models)
On Wed, Aug 12, 2009 at 3:11 AM, Mark Ferrer wrote: > Hi everyone, > This is my first time here, and I've been holding on to some code for a > custom model field type for a little while now. I call it a DictionaryField > and it takes a Python dictionary object and stores it in a database as a > text field. The default storage format is "key1=foo;key2=bar". The > characters used as delimiters and key-value assignments can be changed by > passing in a couple of arguments. When it's fetched from the database > through the orm, the value comes back as a Python dictionary object. It > correctly casts integers and floats. Suggesting this for contrib is premature. The basic criteria for django.contrib is an optional, defacto standard implementation of common patterns. I'm not convinced that this is a common pattern. I'm also not convinced that it's a good pattern to promote in a world of relational databases, but that's a whole different argument. Regardless of my opinion, this is a feature that can happily live external to the Django core. If you want to convince us to put this in django.contrib, then release it as an external project and show us the widespread use that your field receives. Numbers talk. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App Engine support
On Wed, Aug 12, 2009 at 1:49 AM, Waldemar Kornewald wrote: > > On Aug 11, 10:01 am, Malcolm Tredinnick > wrote: >> On Tue, 2009-08-11 at 00:03 -0700, Waldemar Kornewald wrote: >> > And these are just the first few issues we've run into when analyzing >> > the source. >> >> Most of those are the kind of incremental changes that are part of >> making the backend stuff generic. For example, pushing some of the logic >> of the insert/update stuff down into the Query layer is a solution to >> the last point. A lot of the delete stuff is already part of the query >> layer, so it's not much extra to add a layer on the extra stuff. >> >> This is definitely the sort of stuff that is good to know, but initially >> I think it's good to keep phrasing as being specific problems, rather >> than targeting particular solutions, since there is clearly some >> difference in the way you want to go to the way we would like move and >> it's primarily important to understand the problems we're solving, >> rather than spinning around on prematurely debating micro-solutions. > > I thought the high-level consensus already was to move more stuff to > the QuerySet/Query level and allow backends to override Query? Yes. I don't see how what Malcolm said contradicts this. Malcolm was referring to the fact that some of the model level operations - such as delete - are already implemented as interfaces on Query. If you need to move more model functions into the Query to satisfy AppEngine, this is something we are open to discussing. > What > information do you need for refactoring the backend API? A concrete proposal. "I think we should move save() to the Query interface because here is a sample implementation explaining what I mean." As Malcolm said - it's very easy to get stuck in incredibly complex debates of entirely hypothetical situations. The current implementation is sufficient for SQL backends, and is relatively clean in design. You are the expert on AppEngine. You are the person in the position to tell us where you need flexibility that is not currently afforded. Make a concrete proposal, and we'll discuss it. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal for contrib feature (DictionaryField in models)
On Wed, Aug 12, 2009 at 9:02 AM, Jerome Leclanche wrote: > Might be slightly off-topic, but, if that's the main criterion, are we ever > going to include django-tagging in contrib? "Ever" is a very long time. I wouldn't be surprised if _eventually_ django-tagging is added to django.contrib. It is certainly a better candidate for inclusion into django.contrib than the DictField proposal. However, that doesn't mean it will be added in v1.2. Jacob addressed django-tagging directly in his blog entry about django.contrib [1]. To the best of my knowledge, his comments still hold. Most importantly, django-tagging is in no way compromised by being external to django.contrib. The same is true of django-registration, django-profiles, and any number of other popular external packages. [1] http://jacobian.org/writing/what-is-django-contrib/ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Admin interface not preventing simultaneous editing of the same record
On Wed, Aug 12, 2009 at 9:24 AM, David wrote: > > After being unable to get any advice or further information via > google, #django or the users' mailing list, I opened > http://code.djangoproject.com/ticket/11652 regarding the admin > interface not preventing simultaneous editing of the same record (or > at least not providing that as an option). I guess this is not a > typical usage scenario, but for my use case I would like to implement > it if at all possible. You are correct that django.contrib.admin doesn't currently provide protection against simultaneous edits. I can't say this is a problem I've experienced myself. The sites I've dealt with have fairly low traffic admin sites, or only a small number of editors. However, I agree that it would be nice if this sort of protection were to be 'baked in' - preferably at the ModelForm level, if that's not possible, then as a specific extension to admin. > My first thought was to try grab a JSON representation of the original > record in an override of ModelAdmin.change_view; I thought I might be > able to save this via extra_context and somehow get it back when > change_view is called the second time for the HTTP POST of the > modified record. I was hoping to then compare that saved JSON > representation of the original record with the JSON representation of > the record as it exists in the database on that POST call; if they > differed then someone must have changed the record in the meantime and > so I could generate an error message. > > I realized if I added an AutoField data to the record and saved that > instead, then that would be a lot cheaper to save and compare, but I > still don't know how to save that information. There are any number of ways to solve this problem by adding a field to the model (autofield with an 'edit number', timestamp tracking last edit time etc). However, these aren't really candidates for a general solution. > Is there a way to save information in the session and get it back on > subsequent calls? Well... yes... that's what a session is :-) That said, I'm not sure the session is the right place for this. It really needs to be stored per form - consider the case of a single user with multiple tabs open in the admin interface. > Using an AutoField date it would probably be sufficient to just know > when the original GET of the record happened for the user to start > changing it. Is there a way to find that out? > > If anyone has any pointers or advice I'd be most grateful. A few random thoughts: Django's forms already have some functionality that is tangentially related. If you have fields with callable default values, Django will insert a hidden field into the form to contain the initial value. This is required because the value of the callable at time of POST processing may not be the same as the value of the callable when the form is originally displayed. This isn't exactly the same scenario, but it may give you some ideas to see how this could be implemented for the larger problem. Another piece of related work - In the run up to v1.1, a few changes were made to avoid modification issues in FormSets. #10922 described a problem - again, it's not quite the same problem, but it's vaguely related, and may provide some illumination on ways to tackle the problem. A related thought - prior to v1.0, Django's login form would store POST data in a pickle in a hidden field if the login session data expired. This was removed from the login form because an attack vector was demonstrated using this POST data, but as a general approach for checking for modifications, I suspect it could be used here. A hidden field on a form that contains a pickle of the original object data could be added to the field on the original form render; on POST, the pickle could be decompiled to give the original field values for comparison. A somewhat simpler approach would be to use a checksum - calculate an md5/sha hash of the original object data and include it in a hidden field. On submit, recompute the hash based on current values. If the has changed, there have been modifications. I suspect that this would be easier to implement, but would give you slightly less feedback - it would be able to tell you that the object has been modified, but wouldn't be able to tell you the nature of the modifications. Yet another approach would be to only make this 'feature' available to those objects that support it. That is, define a 'ConcurrentModificationField' as an extension of AutoField that you can put on a model; this field would include a default form implementation that does the appropriate validation. This isn't a complete solution, but it could be implemented without any modifications to Django itself. If this is a problem that interests you, then I encourage you to dig around. Developing the code to implement this fix will certainly give you a very good grounding in the internals of Django's form infrastructure. If you can find a clean way
Re: Admin interface not preventing simultaneous editing of the same record
On Wed, Aug 12, 2009 at 10:55 AM, David wrote: > > > > On Aug 11, 10:29 pm, Russell Keith-Magee > wrote: > >> There are any number of ways to solve this problem by adding a field >> to the model (autofield with an 'edit number', timestamp tracking last >> edit time etc). However, these aren't really candidates for a general >> solution. > It didn't occur to me before, but would the History mechanism be any > use here? It must already be tracking edits. An interesting thought. I can't think of any obvious technical reason that the admin Log combined with a timestamp on form submission couldn't be used. You would need to dig into specifics to see if there are any complications, but this is certainly worth looking into. This would fit into the same camp as the checksum solution - it would tell you that a concurrent edit has occurred, but wouldn't tell you how to resolve the concurrent edit. Another cause for hesitation is that it would be an admin-specific solution to the problem. A generic solution that would work for all ModelForms would be nice if it is possible. However, a working solution in admin would be better than a theoretical but non-existent solution in forms. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 1.2 Proposal: django debug toolbar in contrib
On Tue, Aug 11, 2009 at 11:59 PM, Rob Hudson wrote: > > On Tue, Aug 11, 2009 at 7:01 AM, Russell > Keith-Magee wrote: >> Firstly, there is the simple issue of ownership and copyright. >> Obviously, those that have written DDT components that are to be >> included need to be onboard with this idea. > > On this point I've strived to be pro-active (thanks to Jacob)... > before any new commits from new committers were merged I made sure > they're code was ok to be licensed under BSD and they were listed in > the AUTHORS file. Seeing as the "framework" part hasn't changed a > whole lot in the year or so it's been out, it seems like a worthwhile > consideration to me. And I'd be for it. Excellent. > Actually, to my knowledge, all the forks are panel specific and are > not changing the core "framework" part of the debug toolbar. This was my largest technical concern - if the community is using the same interface, then there is is isn't a problem standardizing on that interface. >> Thirdly - look & feel. I haven't used DDT for a while, so I don't know >> what the state of the art is here. Last time I used DDT, it worked >> fine, but I felt that it needed a little UI polish, especially in >> providing a way to hide it or preventing the toolbar from obscuring >> meaningful parts of the underlying site. I don't know how time and >> forking has treated this particular aspect of DDT. > > Agreed. UI isn't my strong point and I've always hoped a designer > would be inspired to give it a full treatment. There's also the > jQuery aspect of it. I think this probably leads to a bigger > discussion. I have a local branch that makes some big improvements in > this area already. At this point, Jacob has pretty much indicated that JQuery is going to be Django's toolkit of choice if/when a toolkit is used. However, we aren't going to impose that choice onto the frontend. Some discussion is definitely required to establish exactly where the boundary ends. I'll be sure to take a closer look at your new UI branch. >> Lastly - time. This needs to be done in a timely fashion. If we're >> going to include DDT in Django v1.2, then we're going to need to have >> a consensus position - if not a ready-to-commit patch, then at least >> agreement on what would be in a ready-to-commit patch - in a little >> over a month. It it takes much longer than that to reconcile the >> forks, then we may need to consider this a work-in-progress for v1.3. > > Perhaps some discussion at DjangoCon? :) Certainly. This sounds like a great topic for a sprint. Russ %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Why does Django make it hard to debug tags?
On Wed, Aug 12, 2009 at 9:45 AM, SmileyChris wrote: > > http://code.djangoproject.com/ticket/11461 > > DebugNodeList catches all exceptions, sticks them in a > TemplateSyntaxError, and stuffs the original exception in the new > exception. I'm not sure why this is done, but it breaks debugging and > exception handling. > > What is the advantage of swallowing the exceptions? I can't speak with authority on the reason behind this, but if I had to guess, I would say this might be a case of confusing intention with accident. This behaviour has existed for at least as long as I can remember, and it's been annoying for pretty much all of that time. To me, this points to a design decision that made sense in the early days (pre-magic removal; maybe even pre public release). That decision may have made sense with an earlier version of Django that didn't have as much potential for exceptions in templates, but it is clearly problematic now. So - Chris - if you want to take on the v1.2 project of making exception handling more meaningful, I say go for it. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: editing django-admin.py
On Thu, Aug 13, 2009 at 12:51 PM, ashish tiwari wrote: > > > when i try to run the "django-admin.py" file in my pardus linux system > than i got the error"c:\python25\python.exebad interpreter" > something like this... > i enter the command "whereis django-admin.py" > and i got the path where it is present... > i open the .py file of django-admin.py from usr/bin/django-admin.py > here is the first line as"#!/c:/python25/python.exe" and i tried to edit > this file... > but i failed to edit itthe popup was came there "access denied..." Django-developers is for discussing the development of Django itself. If you have a "how do I" type question, please ask on django-users. Yours Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 1.2 Proposal: django debug toolbar in contrib
On Thu, Aug 13, 2009 at 5:00 AM, Rob Hudson wrote: > > I'm not sure if this is the place but here are some other issues or > questions I have if this were to happen... This is as good a place as any. > * The jQuery question is a big one. I've taken strides to make the > debug toolbar interoperate with other popular JS frameworks (mootools > and prototype, namely). I acknowledge that dumping jQuery would impose a big redevelopment burden. When I get a spare moment, I'll try and get Jacob to make an pronouncement regarding our JS toolkit usage. > But if jQuery were decided against, would it > make sense to re-use some of the Javascript libraries that Django has > developed for its admin? I'm not sure how much potential for reuse exists here. The javascript in the admin is fairly minimal - the only example of hide+show that I can think of is in collapsing fieldsets, and that code is both simple and written to the specific task. All you're really doing is toggling the class that makes the a particular box visible or hidden. There may be some common themes in the javascript, but I'm not sure it's something that can be re-used. On top of that, there is the possibility that admin will be switched to use jQuery in the near future, so writing the toolbar to depend on admin's javascript could be a short-lived strategy. > * Which set of plugins are included, and of those that have settings, > what are their defaults. Some defaults currently optimize to general > case and provide more debugging information, but on larger sites > performance may suffer severely. It may make sense to take a > philosophy of best default performance with opt-in added debugging. I'm happy to leave this one to the recommendation of yourself and the community. Make a recommendation (and explain your reasoning), and I'll assess it with my Core Dev hat on. I can tell you that I will expect the 'installed by default' set (i.e. the panels you get with no special configuration) to work with no performance hit. More complex panels may be ok if the documentation can clearly explain any limitations that exist. Err on the side of caution - remember that whatever tools you choose will be in Django for the long term, and will be subject to all the standards of performance, robustness and backwards-compatibility of the project as a whole. It's easy to add a panel later on. It's not easy to take one out once it has been added. > * Should there be a place for plugins (panels) that don't make the > cut? Panels consist of some Python and some HTML, so it's not a > single file. They *could* be changed to work similar to form.widgets > with a render method and HTML backed in... but I'm not a huge fan of > that. But it would make it a bit easier for posting on a site like > Django Snippets. It isn't just an advantage for snippets - it also means that deploying a panel is just a matter of referencing the python module - you don't need to do a complex deployment dance with code and templates. Embedding small HTML snippets in a the Python module for a panel seems reasonably elegant to me. The Debug 404 page already does this, so there is precedent in Django, too. > * Should the UI match that of the Django admin (overall theme, colors, > etc)? I'd be inclined to say yes - familiarity would be a good UI device here. BTW: I had a play with the UI refactor - I really like the sidebar layout. > * If the debug toolbar is incorporated, should we consider different > integration options? e.g. Currently the debug toolbar injects URLs > into the project in a rather ugly way -- could this be done better if > it were part of Django? Did you have a something in mind? The middleware approach you have implemented strikes me as reasonably elegant. The only major limitation I can see is that it doesn't allow new panels to provide their own rest-backed capabilities (e.g., imagine if sql_explain was an external panel). One way around this would be to allow panels to define an urls() method; that method could be dynamically inserted into the urlpattern that the debug middleware uses. And while I have your attention... :-) The other two pieces that would be required before we added this to trunk would be documentation and testing. The installation and configuration notes are good, but we need documentation for each panel, and the options for those panels. Tests would also be highly desirable - validating that the REST views work as advertised, that the middleware will operate as expected, etc. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
On Thu, Aug 13, 2009 at 12:04 AM, Michael Glassford wrote: > > http://code.djangoproject.com/ticket/7539 suggests a way to add On > Delete and On Update support to Django foreign key fields, and includes > a patch that implements the suggestions. At the time I submitted it, > getting Django 1.1 out the door prevented it from being seriously > considered, but now that 1.2 is in the planning stages, how about it? > > The ticket actually suggests several changes: > > 1) Adding an on_delete parameter to ForeignKey definitions and allowing > it to specify CASCADE, SET_NULL, or RESTRICT behavior. > > 2) Modifying Django's built-in behavior, which currently always cascades > deletes, to handle the new SET_NULL and RESTRICT behaviors. Django still > defaults to CASCADE behavior for foreign keys that don't specify an > on_delete parameter. > > 3) Allowing settings files to change the default on delete behavior from > CASCADE to one of the other options for foreign keys that don't specify > an on_delete parameter. I'm not convinced that this is a good idea. Explicit is better than implicit. Imagine the case where I write an application with foreign keys that assume CASCADE, since that is the system default; then you deploy in an project where RESTRICT is the default. Hilarity ensues. > 4) Allowing settings files to specify that the on_delete behavior should > be handled by the database backend rather than by Django, and changing > the SQL generated by Django to contain appropriate ON DELETE clauses. > > 5) Adding an on_update parameter to ForeignKey definitions. Unlike the > on_delete parameter, the patch doesn't implement built-in emulation of > on_update: on_update clauses are only handled by the database backend. > > > I believe that items 1-3 are in a form that is usable with little > modification, and would like to suggest that at least this much be added > to 1.2. > > Items 4 and 5 would need more work to support more back ends before it > makes sense to include them. > > It might also be nice to have an implementation of item 5 that doesn't > depend on the db backend, although this might require a significant > amount of work. I'm all in favor of improving the delete cascading support in Django. I have some concerns, however. Firstly: are you volunteering to do the work? These would be interesting additions to Django, but the magic fairy isn't going to write these :-) Secondly: I'm sensitive to the extent that 'on delete cascade' et al are phrased in SQL specific terms. I fully acknowledge the use case - what happens to a FK when the object it points to is deleted - but I want to make sure that we phrase it in a way that makes sense with non-SQL backends. Have you had any thoughts about this? Thirdly: Cross database support - especially when you get to SQL-native implementations - will be a big issue here. Have you done (or are you prepared to do) a survey of the various Django supported backends to find the status of support for various ON DELETE/ON UPDATE options? 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
On Fri, Aug 14, 2009 at 12:06 AM, Michael Glassford wrote: > > Russell Keith-Magee wrote: >> On Thu, Aug 13, 2009 at 12:04 AM, Michael Glassford >> wrote: >>> http://code.djangoproject.com/ticket/7539 suggests a way to add On >>> Delete and On Update support to Django foreign key fields, and includes >>> a patch that implements the suggestions. At the time I submitted it, >>> getting Django 1.1 out the door prevented it from being seriously >>> considered, but now that 1.2 is in the planning stages, how about it? >>> >>> The ticket actually suggests several changes: >>> >>> 1) Adding an on_delete parameter to ForeignKey definitions and allowing >>> it to specify CASCADE, SET_NULL, or RESTRICT behavior. >>> >>> 2) Modifying Django's built-in behavior, which currently always cascades >>> deletes, to handle the new SET_NULL and RESTRICT behaviors. Django still >>> defaults to CASCADE behavior for foreign keys that don't specify an >>> on_delete parameter. >>> >>> 3) Allowing settings files to change the default on delete behavior from >>> CASCADE to one of the other options for foreign keys that don't specify >>> an on_delete parameter. >> >> I'm not convinced that this is a good idea. Explicit is better than >> implicit. Imagine the case where I write an application with foreign >> keys that assume CASCADE, since that is the system default; then you >> deploy in an project where RESTRICT is the default. Hilarity ensues. > > True enough. > > When you say "explicit is better...", are you recommending requiring all > foreign keys to specify an on_delete option, or only those that don't > want to CASCADE (I assume the latter)? The latter. All existing model definitions must continue to work the same without modification. If we add an option, that option must default to historical behavior. > There are still people who are > surprised by the CASCADE default behavior, which is why I suggested the > setting in the first place. Having CASCADE as a default may be surprising, but we're not in a position to change that - it's the current default, so we're stuck with it. As indicated, adding a system wide setting has other consequences. This is one of those situations where "just add a setting" makes the problem worse, not better. >>> 4) Allowing settings files to specify that the on_delete behavior should >>> be handled by the database backend rather than by Django, and changing >>> the SQL generated by Django to contain appropriate ON DELETE clauses. >>> >>> 5) Adding an on_update parameter to ForeignKey definitions. Unlike the >>> on_delete parameter, the patch doesn't implement built-in emulation of >>> on_update: on_update clauses are only handled by the database backend. >>> >>> >>> I believe that items 1-3 are in a form that is usable with little >>> modification, and would like to suggest that at least this much be added >>> to 1.2. >>> >>> Items 4 and 5 would need more work to support more back ends before it >>> makes sense to include them. >>> >>> It might also be nice to have an implementation of item 5 that doesn't >>> depend on the db backend, although this might require a significant >>> amount of work. >> >> I'm all in favor of improving the delete cascading support in Django. >> >> I have some concerns, however. >> >> Firstly: are you volunteering to do the work? These would be >> interesting additions to Django, but the magic fairy isn't going to >> write these :-) > > As far as I know, the work for items 1-3 is already done and in the > patch (though it may need to be updated). This is all I'm suggesting > adding to Django 1.2. I have no problem with items 1-2. Item 3 probably isn't an option, as I have indicated. > Item 4 is done for MySQL; I'm not really in a position to extend it to > other backends, which is why I'm not suggesting it for Django 1.2. > > Item 5 (without the suggested addition of building ON UPDATE behavior > into Django itself) is also done for MySQL. Again, I'm not in a position > to extend it to other backends. I might be able to do the work to add > the ON UPDATE behavior to Django itself at some point, but probably not > for 1.2. Ok - there's no reason this can't be tackled in multiple stages. >> Secondly: I'm sensitive to the extent that 'on delete cascade' et al >> are phrased in SQL specific terms. I fully acknowledge the use cas
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
On Fri, Aug 14, 2009 at 9:16 AM, Michael Glassford wrote: > > Russell Keith-Magee wrote: >>>> Secondly: I'm sensitive to the extent that 'on delete cascade' et al >>>> are phrased in SQL specific terms. I fully acknowledge the use case - >>>> what happens to a FK when the object it points to is deleted - but I >>>> want to make sure that we phrase it in a way that makes sense with >>>> non-SQL backends. Have you had any thoughts about this? >>> I think the three options I included (CASCADE, RESTRICT, and SET_NULL) >>> make sense for non-SQL backends, although I'd be glad to rename them and >>> use non-SQL terminology. >> >> There are two aspects to consider - naming and functionality. > > So how about these options with this naming: > > CASCADE (or CASCADE_DELETE) > PREVENT (or PREVENT_DELETE) (prevents anything from being deleted) > SET_NONE > SET_DEFAULT I'm not wild about PREVENT, but it will do for now. There's a risk that this will turn into a bikeshed argument; at this point, formal acceptance of the concept and a working patch are much more important. >> ~ >> >> I'm broadly in favour of this proposal. There are some details that >> may need to be sorted out, but they're mostly porcelain, not plumbing >> - the core of the feature proposal itself is well defined. >> >> So, all that is left is to stick the ticket on the v1.2 Feature wiki >> page so that it is considered when the time comes. > > Should I do this? Yes. You want the feature, you advocate for it :-) >> Also, keep working on the patch. I notice that the latest patch >> doesn't contain any tests or documentation (although the earlier patch >> contains tests) - both will be required before the feature lands. > > Really, the tests are missing? That was an accidental omission, then--I > still have the tests running locally. > > Once we agree on naming changes, I'll work up a patch that implements > only items 1-2, with the naming changes, including tests. > > What's the best way to add documentation? Should it be a patch against > the existing docs? Yes. The single patch should be ready to commit, with tests to prove that the feature works, and any docs to tell people how to use it. My work should be limited to "patch -p0 < cascade.diff && svn commit". I've had a cursory glance at the patch. Some quick things that stood out: * We are trying to keep SQL-specific stuff out of the codebase except for the sql.Query backend. Defining CASCADE et all as classes that contain SQL snippets isn't a good solution, as someone soon will be trying to write a non-SQL backend, and will need to use the same values. A simple constant will suffice. * The value for on_delete should be set as a property of the field; if there is a default, that default should be reflected on the field, rather than interpreting a None value every time it is encountered. * The patch makes reference to using MySQL error numbers. Erm... No. :-) 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
On Sat, Aug 15, 2009 at 8:09 AM, hcarvalhoalves wrote: > > On Aug 13, 9:30 am, Russell Keith-Magee > wrote: >> On Thu, Aug 13, 2009 at 12:04 AM, Michael Glassford >> wrote: >> >> Secondly: I'm sensitive to the extent that 'on delete cascade' et al >> are phrased in SQL specific terms. I fully acknowledge the use case - >> what happens to a FK when the object it points to is deleted - but I >> want to make sure that we phrase it in a way that makes sense with >> non-SQL backends. Have you had any thoughts about this? > > Maybe using the UML terms to declare these associations, as it makes > sense in an ORM environment, and is not SQL specific. > > ForeignKey(composition=True) > Strong association -> relates to SQL's CASCADE or similar behavior on > custom backends > > ForeignKey(aggregation=True) > Weak association -> relates to SQL's SET_NULL or similar behavior on > custom backends > > ForeignKey(restrict=True) > Optional restrict to raise Exception on delete -> relates to SQL's > RESTRICT This is an interesting idea - it's nicely object-based, and it gets around the SQL-specific terminology. However, it does introduce some nasty term-overloading with the phrase "aggregation". However, the 'strong/weak' distinction is an interesting starting point for some language. A proposal: ForeignKey(XXX, association=STRONG) - The current arrangement, equivalent to SQL ON DELETE CASCADE ForeignKey(XXX, association=WEAK, null=True) - The equivalent of SQL ON DELETE SET NULL ForeignKey(XXX, association=WEAK, default=xxx) - The equivalent of SQL ON DELETE SET DEFAULT ForeignKey(XXX, association=PROTECTED) - The equivalent of SQL ON DELETE RESTRICT. Deletion is prevented. For completeness: ForeignKey(XXX, association=WEAK) would be an error, since the field doesn't allow NULLs, but an alternate default value hasn't been specified. Opinions? 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: admin reuse
On Sat, Aug 15, 2009 at 3:52 PM, Haroldo Stenger wrote: > I've seen the admin evolve to very sophisticated user interaction. > Nonetheless, the param to HttpResponse() when a model object has been > saved, is hardcoded and most of the times "../../.." or "../.." (see > options.py in contrib.admin). This is a historical artefact. As of v1.1, the 'right way' to do this would be to use a named URL pattern. Some of the usages of '../..' paths have been corrected, but there are still some remaining. It doesn't harm anything while they remain, but I expect that they will eventually get cleaned up. > Being able to change that string by some means > of instantiation or runtime configuration, could allow a view to use the > admin to edit an object, and once the model object has been saved modified, > automatically return to the view (or another view registered in URLconf). I > wonder if this has ben thought before, and if there would be much resistance > to a change in that HttpResponse's parameter flexibility. I'm not sure I see why this parameter needs to be configurable. When you save an object, it goes back to the list of objects of the same type. I can't think of any other logical place for the view to redirect. It sounds like you're trying to use the admin edit views within your own application. If this is the case, let me advise you that Django's admin isn't intended as a way to avoid writing edit views for your own site. If you want to edit objects in your own site, just write write edit views - it isn't that hard to use a modelform. If you have another use case, I'd be interested to hear it. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
On Sat, Aug 15, 2009 at 10:57 AM, Michael Glassford wrote: > > Russell Keith-Magee wrote: >> On Sat, Aug 15, 2009 at 8:09 AM, hcarvalhoalves >> wrote: >>> On Aug 13, 9:30 am, Russell Keith-Magee >>> wrote: >>>> On Thu, Aug 13, 2009 at 12:04 AM, Michael Glassford >>>> wrote: >>>> >>>> Secondly: I'm sensitive to the extent that 'on delete cascade' et al >>>> are phrased in SQL specific terms. I fully acknowledge the use case - >>>> what happens to a FK when the object it points to is deleted - but I >>>> want to make sure that we phrase it in a way that makes sense with >>>> non-SQL backends. Have you had any thoughts about this? >>> Maybe using the UML terms to declare these associations, as it makes >>> sense in an ORM environment, and is not SQL specific. >>> >>> ForeignKey(composition=True) >>> Strong association -> relates to SQL's CASCADE or similar behavior on >>> custom backends >>> >>> ForeignKey(aggregation=True) >>> Weak association -> relates to SQL's SET_NULL or similar behavior on >>> custom backends >>> >>> ForeignKey(restrict=True) >>> Optional restrict to raise Exception on delete -> relates to SQL's >>> RESTRICT >> >> This is an interesting idea - it's nicely object-based, and it gets >> around the SQL-specific terminology. However, it does introduce some >> nasty term-overloading with the phrase "aggregation". >> >> However, the 'strong/weak' distinction is an interesting starting >> point for some language. A proposal: >> >> ForeignKey(XXX, association=STRONG) >> - The current arrangement, equivalent to SQL ON DELETE CASCADE >> >> ForeignKey(XXX, association=WEAK, null=True) >> - The equivalent of SQL ON DELETE SET NULL >> >> ForeignKey(XXX, association=WEAK, default=xxx) >> - The equivalent of SQL ON DELETE SET DEFAULT >> >> ForeignKey(XXX, association=PROTECTED) >> - The equivalent of SQL ON DELETE RESTRICT. Deletion is prevented. >> >> For completeness: >> >> ForeignKey(XXX, association=WEAK) >> >> would be an error, since the field doesn't allow NULLs, but an >> alternate default value hasn't been specified. >> >> Opinions? > > I think more people would understand the on_delete= than the > association= terminology without having to look it up; but I'd have no > problem implementing it this way if it's what gets decided on. Are you saying that a user who discovers on_delete=PREVENT in a model won't need to do exactly the same thing? What does PREVENT mean? It doesn't have an SQL equivalent - what is going to be prevented? If you want to argue that association=STRONG et al is a bad conceptual abstraction, thats fine. However, I won't accept the argument that on_delete=CASCADE is better because it is somehow renders the user immune from a need to read documentation. We _want_ users to read the documentation on a feature before they use it. We _want_ to break the assumptions they might bring with regard to SQL implementations. > How would the equivalent of ON UPDATE be handled in this type of scheme, > assuming it gets added at some point? What aspect of ON UPDATE are you looking to implement? It isn't immediately obvious to me that ON UPDATE is a good idea, or one that has a natural object-based interpretation. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
On Sat, Aug 15, 2009 at 10:46 PM, Michael Glassford wrote: > > Russell Keith-Magee wrote: >> On Sat, Aug 15, 2009 at 10:57 AM, Michael Glassford >> wrote: >>> Russell Keith-Magee wrote: >>>> On Sat, Aug 15, 2009 at 8:09 AM, hcarvalhoalves >>>> wrote: >>>>> On Aug 13, 9:30 am, Russell Keith-Magee >>>>> wrote: >>>>>> On Thu, Aug 13, 2009 at 12:04 AM, Michael >>>>>> Glassford wrote: >>>>>> >>>>>> Secondly: I'm sensitive to the extent that 'on delete cascade' et al >>>>>> are phrased in SQL specific terms. I fully acknowledge the use case - >>>>>> what happens to a FK when the object it points to is deleted - but I >>>>>> want to make sure that we phrase it in a way that makes sense with >>>>>> non-SQL backends. Have you had any thoughts about this? >>>>> Maybe using the UML terms to declare these associations, as it makes >>>>> sense in an ORM environment, and is not SQL specific. >>>>> >>>>> ForeignKey(composition=True) >>>>> Strong association -> relates to SQL's CASCADE or similar behavior on >>>>> custom backends >>>>> >>>>> ForeignKey(aggregation=True) >>>>> Weak association -> relates to SQL's SET_NULL or similar behavior on >>>>> custom backends >>>>> >>>>> ForeignKey(restrict=True) >>>>> Optional restrict to raise Exception on delete -> relates to SQL's >>>>> RESTRICT >>>> This is an interesting idea - it's nicely object-based, and it gets >>>> around the SQL-specific terminology. However, it does introduce some >>>> nasty term-overloading with the phrase "aggregation". >>>> >>>> However, the 'strong/weak' distinction is an interesting starting >>>> point for some language. A proposal: >>>> >>>> ForeignKey(XXX, association=STRONG) >>>> - The current arrangement, equivalent to SQL ON DELETE CASCADE >>>> >>>> ForeignKey(XXX, association=WEAK, null=True) >>>> - The equivalent of SQL ON DELETE SET NULL >>>> >>>> ForeignKey(XXX, association=WEAK, default=xxx) >>>> - The equivalent of SQL ON DELETE SET DEFAULT >>>> >>>> ForeignKey(XXX, association=PROTECTED) >>>> - The equivalent of SQL ON DELETE RESTRICT. Deletion is prevented. >>>> >>>> For completeness: >>>> >>>> ForeignKey(XXX, association=WEAK) >>>> >>>> would be an error, since the field doesn't allow NULLs, but an >>>> alternate default value hasn't been specified. >>>> >>>> Opinions? >>> I think more people would understand the on_delete= than the >>> association= terminology without having to look it up; but I'd have no >>> problem implementing it this way if it's what gets decided on. >> >> Are you saying that a user who discovers on_delete=PREVENT in a model >> won't need to do exactly the same thing? What does PREVENT mean? It >> doesn't have an SQL equivalent - what is going to be prevented? > > True, they would have to look up PREVENT, but probably not CASCADE, > SET_NULL, or SET_DEFAULT. > >> If you want to argue that association=STRONG et al is a bad conceptual >> abstraction, thats fine. However, I won't accept the argument that >> on_delete=CASCADE is better because it is somehow renders the user >> immune from a need to read documentation. We _want_ users to read the >> documentation on a feature before they use it. We _want_ to break the >> assumptions they might bring with regard to SQL implementations. > > I'm not really arguing in favor of it, just mentioning that more people > will be familiar with the on_delete concept. At this point I don't have > a strong preference for either method over the other. I do think I would > prefer either method to nothing at all. > > One more question that occurred to me this morning is, what would this do: > > ForeignKey(XXX, association=WEAK, null=True, default=xxx) > - Is this the equivalent of SET NULL or SET DEFAULT? SET DEFAULT. The SET-equivalent options are based entirely on the value of `default`. The `null` argument doesn't affect this feature. SET NULL is just the special case when you (implicitly or explicitly) have default=None. Keep in mind that: ForeignKey(XXX) is actually an implicit version of: ForeignKey(XXX, default=None) but if you have default=None, you'd better have null=True as well, or else you're going to get validation errors (since null=False is the implicit setting). Yes, this does mean you can't specify a default but have FK's reset to NULL. However, to my mind, that's what a default means. Again - we're not trying to reproduce SQL here, we're trying to come up with an object model that makes sense. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
On Sun, Aug 16, 2009 at 1:45 AM, hcarvalhoalves wrote: > > On Aug 14, 11:48 pm, Russell Keith-Magee > wrote: >> On Sat, Aug 15, 2009 at 8:09 AM, hcarvalhoalves >> wrote: >> >> > On Aug 13, 9:30 am, Russell Keith-Magee >> > wrote: >> >> On Thu, Aug 13, 2009 at 12:04 AM, Michael Glassford >> >> wrote: >> >> >> Secondly: I'm sensitive to the extent that 'on delete cascade' et al >> >> are phrased in SQL specific terms. I fully acknowledge the use case - >> >> what happens to a FK when the object it points to is deleted - but I >> >> want to make sure that we phrase it in a way that makes sense with >> >> non-SQL backends. Have you had any thoughts about this? >> >> > Maybe using the UML terms to declare these associations, as it makes >> > sense in an ORM environment, and is not SQL specific. >> >> > ForeignKey(composition=True) >> > Strong association -> relates to SQL's CASCADE or similar behavior on >> > custom backends >> >> > ForeignKey(aggregation=True) >> > Weak association -> relates to SQL's SET_NULL or similar behavior on >> > custom backends >> >> > ForeignKey(restrict=True) >> > Optional restrict to raise Exception on delete -> relates to SQL's >> > RESTRICT >> >> This is an interesting idea - it's nicely object-based, and it gets >> around the SQL-specific terminology. However, it does introduce some >> nasty term-overloading with the phrase "aggregation". >> > > This is UML, so anyone familiar with it understands Composition vs > Aggregation. It doesn't help if the person doesn't know UML, of > course, but I'm not just coming up with names of my own - it's an > industry standard. OTH, WEAK and STRONG are terms used neither by SQL > or UML, so I would be less in favor of using something like this. Yes. However, I challenge you to point at a single other place in Django where UML notation or syntax is used. I'm sure COBOL has some great turns of phrase too - doesn't mean we'll use them. My issue isn't that Composition and Aggregation aren't good terms by themselves. My problem is that we already have Model.objects.aggregate() in the API, which has nothing to do with UML or cascading deletes. We need to avoid naming collisions like this. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
On Sun, Aug 16, 2009 at 12:31 PM, hcarvalhoalves wrote: > > On Aug 15, 8:53 pm, Russell Keith-Magee > wrote: >> On Sun, Aug 16, 2009 at 1:45 AM, hcarvalhoalves >> wrote: >> >> > On Aug 14, 11:48 pm, Russell Keith-Magee >> > wrote: >> >> On Sat, Aug 15, 2009 at 8:09 AM, hcarvalhoalves >> >> wrote: >> >> >> > On Aug 13, 9:30 am, Russell Keith-Magee >> >> > wrote: >> >> >> On Thu, Aug 13, 2009 at 12:04 AM, Michael >> >> >> Glassford wrote: >> >> >> >> Secondly: I'm sensitive to the extent that 'on delete cascade' et al >> >> >> are phrased in SQL specific terms. I fully acknowledge the use case - >> >> >> what happens to a FK when the object it points to is deleted - but I >> >> >> want to make sure that we phrase it in a way that makes sense with >> >> >> non-SQL backends. Have you had any thoughts about this? >> >> >> > Maybe using the UML terms to declare these associations, as it makes >> >> > sense in an ORM environment, and is not SQL specific. >> >> >> > ForeignKey(composition=True) >> >> > Strong association -> relates to SQL's CASCADE or similar behavior on >> >> > custom backends >> >> >> > ForeignKey(aggregation=True) >> >> > Weak association -> relates to SQL's SET_NULL or similar behavior on >> >> > custom backends >> >> >> > ForeignKey(restrict=True) >> >> > Optional restrict to raise Exception on delete -> relates to SQL's >> >> > RESTRICT >> >> >> This is an interesting idea - it's nicely object-based, and it gets >> >> around the SQL-specific terminology. However, it does introduce some >> >> nasty term-overloading with the phrase "aggregation". >> >> > This is UML, so anyone familiar with it understands Composition vs >> > Aggregation. It doesn't help if the person doesn't know UML, of >> > course, but I'm not just coming up with names of my own - it's an >> > industry standard. OTH, WEAK and STRONG are terms used neither by SQL >> > or UML, so I would be less in favor of using something like this. >> >> Yes. However, I challenge you to point at a single other place in >> Django where UML notation or syntax is used. I'm sure COBOL has some >> great turns of phrase too - doesn't mean we'll use them. > > The point is, using terms that are agreed upon. My idea was using UML > terms, which is a standard in OO modeling, the same way as ForeignKey > is used, which is a term from ER modeling. I don't know what you tried > by comparing UML to COBOL, but I'm not even going further on this > because... I introduced COBOL because it has about as much relevance to Python as UML does. >> My issue isn't that Composition and Aggregation aren't good terms by >> themselves. My problem is that we already have >> Model.objects.aggregate() in the API, which has nothing to do with UML >> or cascading deletes. We need to avoid naming collisions like this. > > ... you're right, I forgot that the term is used in other context for > the ORM already. > > Anyway, I insist on using known, widespread terms for this as possible. Firstly - you can insist all you like, but I'm the one with commit access. :-) Secondly, Weak and Strong _are_ widespread terms. They are used in Python and a number of other OO languages when used to refer to object references. Thirdly, at some point, this becomes a bikeshed. I'm willing to entertain discussion on finding a good term, but at some point we have to just choose something and move on. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #6148. Should database schemas be created as well?
On Mon, Aug 17, 2009 at 11:12 PM, Ian Kelly wrote: > > On Mon, Aug 17, 2009 at 8:19 AM, kmpm wrote: >> >> I'm working on issue http://code.djangoproject.com/ticket/6148 and >> have some questions. >> >> If a db_schema is defined, should it be created automatically or >> should the user be required to set this up in the same fashion as he >> is required to set up the database. >> >> For postgres it might not be any trouble to create the schema within >> the pre existing database but the MySQL implementation of schemas is >> to create a additional database for the schema (CREATE SCHEMA is a >> alias of CREATE DATABASE). This seems a bit to intrusive for my taste >> and that's why I'm asking. > > Also in Oracle, creating a schema means creating a user, which has > security implications. My opinion is that we should not be actively > meddling with schemas, just as we do not with databases, users, or > tablespaces. I concur. I see schemas as a gross organizational structure, just like the database itself. Django doesn't create the database; by extension, I see no reason that it should create the schema either. Implementation complications (such as those under Oracle and MySQL) only serve to reinforce this point. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #11627: Test suites in test framework
2009/8/18 Filip Gruszczyński : > > What I was thinking, is to provide all Test classes (both cases and > suites) as class attributes in a modified TestSuite. When such a > TestSuite is run using django framework, it would feed with proper > instances, basing on those classes. This way end user would be able to > group his tests easily - just create a TestSuite and TestCases/Suites > it uses and all the magic would be done by us. What do you think about > it? I don't think I understand your proposal. An example would be extremely helpful here. Under your proposal, what would my new tests.py look like? How would I invoke a single test? A single test case? A single suite? Some guidelines that might help you shape your proposal: * Existing code must continue to run unmodified. This is the cornerstone of Django's backwards compatibility guarantee. * The way you construct and invoke tests must not become needlessly complicated. For example: the current test runner lets you specify app.TestCase.test_name to run an individual test. In the presence of suites, it makes sense that this might be extended to app.suite_name.TestCase.test_name. However, the interface should not _require_ the specification of a "default" suite - either in the definition of tests, or in the name provided when executing tests. The user should be able to continue to define just TestCases, and to invoke them by providing just app.TestCase. > Another aspect is: when several TestCases are first created and then > passed to a TestSuite, should they be run twice, if user just calls > ./manage.py test? Once as a standalone TestCase and then in a > TestSuite? The TestSuite is purely an organizational tool. There is no benefit to running a TestCase twice reflecting the different ways it has been filed. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #11627: Test suites in test framework
2009/8/18 Filip Gruszczyński :
>
>> I don't think I understand your proposal. An example would be
>> extremely helpful here. Under your proposal, what would my new
>> tests.py look like? How would I invoke a single test? A single test
>> case? A single suite?
>
> That's not exactly my proposal. Proposal was reported by someone else
> and the ticket was accepted, so I hoped I could sit down to it. It
> seemed confined and would allow to get a very close look at the test
> framework, so I would like to try and code it.
>
> That it must be backward compatible is very clear to me. The example
> would look like this:
>
> class TestCase1(TestCase):
>
> ..
>
> class TestCase2(TestCase):
>
> ..
>
> class TestSuite1(TestSuite):
> case1 = TestCase1
> case2 = TestCase2
>
> Now you can run:
> ./manage.py test app.TestCase1
>
> or if you wish
> ./manage.py test app.TestSuite1
>
> and TestSuite1 would run all test cases, that were specified in test suite,
Ok - your proposal now makes a lot more sense. However, I think you're
stepping outside the original request of the ticket.
The idea behind suites is to provide a way to group tests that doesn't
necessarily correlate to your TestCase structure. For example, you
could have:
class WidgetTestCase(TestCase):
def testW1(self):
def testW2(self):
class GadgetTestCase(TestCase):
def testG1(self):
def testG2(self):
def suiteA():
suite = unittest.TestSuite()
suite.addTest(WidgetTestCase('testW1'))
suite.addTest(WidgetTestCase('testW2'))
suite.addTest(GadgetTestCase('testG2'))
return suite
def suiteB():
suite = unittest.TestSuite()
suite.addTest(WidgetTestCase('testW2'))
suite.addTest(GadgetTestCase('testG1'))
suite.addTest(GadgetTestCase('testG2'))
return suite
Here we have defined 2 test suites, from overlapping subsets of the
underlying test cases.
Ticket #11627 is asking for a way to invoke individual test suites as
a command line option to test - that is, in addition to the following:
./manage.py test
./manage.py test app
./manage.py test app.WidgetTestCase
./manage.py test app.WidgetTestCase.testW1
you should also be able to invoke
./manage.py test app.suiteA
Your proposal covers this issue of invoking test suites. This should
be a fairly simple issue to resolve - it's just a matter of modifying
the test runner to look for a suite with the appropriate name before
it goes the process of discovering TestCase instances and building a
default suite.
However, in addition to this lookup problem, you also seem to be
proposing a new technique for defining suites. While I'm all in favor
of proposals that make it easier to construct test suites, I'm not
sure your proposal is that strong - for instance, unless I'm mistaken,
the simple example I gave (which is a completely legal suite) couldn't
be composed using your proposed syntax.
If you want to pursue this idea of making it easier to define suites,
please open a second ticket - the two ideas don't need to get mixed
together.
> As I understand the need (once again, I am not the reporter, I am
> trying to understand, how it should work too) this would allow you to
> group some tests from an app and instead of calling all the tests from
> an app or specify them explictly, you group them in a suite and run
> just the suite. This might be useful, if there are plenty of tests in
> an app and you would like to run only a subset of them, which still
> might be significantly large. Then you build a suite and you can
> specify only this suite. But maybe Alex had something different in
> mind - if he could specify it better, I'd love to conform to this. At
> this point I am not very into any design decisions, not with mu
> current knowledge of Django. I'd would like to dive into the code base
> and learn. This seemed as a good start.
This is quite a good pick for a "first bug". It's fairly small, but
hits on some interesting parts of the Django test framework.
Just make sure you solve the original problem - don't get carried away
trying to solve a problem that is outside the original problem
definition.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
On Wed, Aug 19, 2009 at 1:43 AM, drakkan wrote: > > Hey guys, > > not a flame only a consideration: the best python orm/sql toolkit > (sqlalchemy) already support this and many many other features/ > database engines, why not move the efforts in sa integration? Using sa > in django is simple but actually you cannot use admin interface On the off chance that this was a well intentioned comment, and not just at troll, I will point out that: * "Best Python ORM/SQL toolkit" is a _huge_ value judgement. * SQLAlchemy has explicitly stated that they aren't going to attempt to solve one of the problems that Django is explicitly trying to target - support for non-relational data stores. We aren't going to adopt a toolkit that has said they aren't going to address a problem we want to solve. That said, James is correct that this isn't a topic that requires debate. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #11627: Test suites in test framework
2009/8/19 Filip Gruszczyński : > > Still, I've got a question: if someone creates a suit through a > function, how should it be invoked? Only explicitly > app.module.suite_function or if run ./manage.py test should this suite > be also invoked (and then some tests will be run twice)? I see no reason that the existing behavior needs to change in any significant way. At present, the test suite called "suite" is the entry point for manage.py test. If this suite isn't defined, all TestCases in the module will be loaded into a default suite and executed. The only difference with what you are proposing is that it will be possible to invoke suites with a name other than 'suite'. Unless the user defines a 'suite' function that composes the individual suites into a single master suite, extra suite definitions shouldn't interact with the existing test execution. A summary of what I see as appropriate behaviour: ./manage.py test app - if defined, run suite() - otherwise, run all TestCases in module ./manage.py test app.MyTestCase - runs test case MyTestCase ./manage.py test app.MyTestCase.test_stuff - runs the single test_stuff test case from MyTestCase ./manage.py test app.mysuite - runs contents of mysuite() ./manage.py test app.suite - equivalent to ./manage.py test app, except that it requires the existence of a test suite - error if no suite() function is defined. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 1.2 proposal: revisit admin autodiscover improvement for custom sites
On Thu, Aug 20, 2009 at 8:36 AM, Brian Rosner wrote: > > > On Aug 19, 2009, at 3:32 PM, Manuel Saelices wrote: > >> This ticket was marked by duplicate of #8500, but I think #8572 >> approach is better (better explicit than implicit). Ticket number is >> not important, but I think that functionality is easy to implement >> (with several strategies) and has no colateral effects, being >> backwards compatible. > > I am in agreement the approach in #8572 is best. This has something > that has bitten me on a few occasions and would like to get this fixed > in Django. If you are fired up about getting this in I would recommend > including documentation and tests and attaching it to #8500. > > Of course I welcome the thoughts of others too. #8572 looks like a much better approach to me. I also agree that this is a problem worth addressing - anything that allows breaking the dependency on a hardcoded default is almost always good in my book. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Inline formsets
On Sun, Aug 16, 2009 at 5:45 AM, mrts wrote:
>
> At HTML level, a form is a set of fields that gets submitted when
> a the form submit button is pressed.
>
> However, this is not the case with model forms and inline formsets
> (e.g. an admin page with inlines) -- inline formsets are
> disparate from the model form.
>
> This creates at least two problems:
> 1) it's impossible to display inline formsets in between ordinary
> form fields (although they may logically belong to a particular
> fieldset and not to the end of the form),
This is only true if you consider {{ form }} to be the only way to
render a form. Remember - you can modify your template to render
individual fields on a form. If you're looking for sophisticated
layout options, you should be looking at customizing your template,
not trying to turn Django's Form.as_ul into the One True Form
Rendering Tool (tm).
> 2) it's impossible to create nested (recursive) inlines.
This is true, but not necessarily a bad thing. I'm willing to be
convinced otherwise, but I'm yet to see a case where nested inlines
would yield a positive user experience. Forms inside forms inside
forms is a recipe for UI disaster.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: #10355 Add support for email backends
On Fri, Aug 21, 2009 at 12:34 PM, Andi Albrecht wrote: > > Hi, > > I'm interested in working on #10355 "Add support for email backends." > > IMHO it's an good idea to make the email backend configurable. There > are at least two use cases I can think of. The first is to send email > with other services than SMTP, like App Engine as noted in the > ticket's description. The second is to deliver email asynchronously, > like the django-mailer application does already. > > The ticket currently needs a design decision, so my question is what > the actual concerns to change this are. I think the original concern was the time required to triage the ticket :-) The original report is fairly light on detail, so I suspect Jacob punted the proposal to DDN in a fit of rapid triage. However, your proposal gives us a bit more detail to work with. On the whole, I have to say I like what I see. This is the sort of thing I'd like to see more of in Django - less specific feature enhancements baked into the core, and more opening of interfaces that let people plug their own capabilities in where they need to. > I would propose the following changes. It's a very simplistic approach > that tries to keep the current API as much as possible: To qualify this - "as much as possible" must include "100% backwards compatible with 0 code changes with all public advertised interfaces". > Add a new setting EMAIL_BACKEND. A string that can be resolved to a > class. Default should be the current SMTP implementation. No problem with this, and follows the precedent set by other backends (such as the cache backend) > Provide a base class for mail backends. A mail backend must provide > the method send_messages(email_messages) and must return the number of > messages sent to provide backward compatibility. The constructor of a > mail backend should take at least the keyword argument fail_silently > (default: False). What I'm a bit unsure about are additional > constructor arguments. Currently the SMTP backend allows in addition > host, port, username, password and use_tls. Those are very > SMTP-specific, but only username and password are used by the > mail.send_mail* APIs. It would be an agreement to allow username and > password in addition to fail_silently to not break the send_mail* API. I'll need to look into this in more detail. I'm hesitant to lock down APIs like this too much - the more rigid you make an interface, the harder it becomes to use it in interesting way. I'm sure that some insights will emerge as a result of writing the code. > The SMTP backend could accept host, port and use_tls as extra keywords > again to provide backward compatibility for code that directly uses > SMTPConnection (within Django SMTPConnection is not used outside > django.core.mail). I would suggest to rename SMTPConnection to > SMTPBackend, but only if this would break too much third-party code as > SMTPConnection is mentioned in the docs. Breaking _any_ third party code is a non-starter. We can deprecate the old name and provide an alias from the old name to the new name, but historical usage must continue without modification. > The test utils could be refactored to use a TestMailBackend instead of > monkey-patching the mail module, but this would be a fairly invisible > change as it would just change the way how the test utils provide the > mailbox attribute in the mail module for unittests. This is an interesting suggestion all by itself. It also dovetails nicely with #8638. That ticket was on the list for v1.1, and originally proposed including a 'test email server'. Ultimately, it was decided not to include an email server, but to document the ways you could use existing mail servers. A 'test email backend' (as well as a dummy no-mail-at-all backend, and a log-to-console/log-to-file backend) is a different way to target the underlying problem posed by #8638. > A nice addition to Django would be to include parts of django-mailer > to provide a backend for asynchronous mail delivery. That could be the > models and command line script to deliver mails. While thinking about > this, django-mailer has a nice option for setting priorities to mails. > IMO Django's API for sending mails should be as simple as possible > (like it is today), but a priority option would be a nice addition > even if the SMTP backend (as the default) wouldn't respect this option > when sending mails. I'm aware of the existence of django-mailer, but I haven't looked into it in detail. At least for the first cut, I'd be more comfortable seeing django-mailer-esque capabilities living as a community project. Then, maybe in the v1.3 timeframe, we can look at adding it as a 'batteries included' backend. That said - if a prototype django-mailer backend were to be developed as part of this development effort, it would go a long way to proving that the backend API you are proposing is sufficiently flexible. The code doesn't need to be trunk-ready, but if you can prove tha
Re: #10355 Add support for email backends
On Fri, Aug 21, 2009 at 5:53 PM, Zachary Voase wrote: > > Hi Andi, > > On 21 Aug 2009, at 05:34, Andi Albrecht wrote: > >> Hi, >> >> I'm interested in working on #10355 "Add support for email backends." >> >> IMHO it's an good idea to make the email backend configurable. There >> are at least two use cases I can think of. The first is to send email >> with other services than SMTP, like App Engine as noted in the >> ticket's description. The second is to deliver email asynchronously, >> like the django-mailer application does already. > > I wholeheartedly agree. > >> The ticket currently needs a design decision, so my question is what >> the actual concerns to change this are. >> >> I would propose the following changes. It's a very simplistic approach >> that tries to keep the current API as much as possible: >> >> Add a new setting EMAIL_BACKEND. A string that can be resolved to a >> class. Default should be the current SMTP implementation. >> >> Provide a base class for mail backends. A mail backend must provide >> the method send_messages(email_messages) and must return the number of >> messages sent to provide backward compatibility. The constructor of a >> mail backend should take at least the keyword argument fail_silently >> (default: False). What I'm a bit unsure about are additional >> constructor arguments. Currently the SMTP backend allows in addition >> host, port, username, password and use_tls. Those are very >> SMTP-specific, but only username and password are used by the >> mail.send_mail* APIs. It would be an agreement to allow username and >> password in addition to fail_silently to not break the send_mail* API. >> The SMTP backend could accept host, port and use_tls as extra keywords >> again to provide backward compatibility for code that directly uses >> SMTPConnection (within Django SMTPConnection is not used outside >> django.core.mail). I would suggest to rename SMTPConnection to >> SMTPBackend, but only if this would break too much third-party code as >> SMTPConnection is mentioned in the docs. > > This I disagree with slightly. My main concern is the single-backend > architecture; many websites will probably want to use more than one > method for sending e-mail. I'm not sure I agree with your assertion of "many"."Some" might be accurate. "Your" is probably more accurate :-) I've got many websites in the field, and not one of them has needed anything more than trivial email handling. We've managed to get to v1.1 and AppEngine support is the first time that pluggable email backends have really been raised as an issue. This is hardly surprising. After all, email is email. You have an SMTP server, you connect to it, you send your mail. AppEngine is a weird case in that they provide an email-sending API rather than using SMTP, but that's an artefact of the platform. Once you have one email sending capability, I find it hard to believe that most people will need a second. I don't doubt that there are applications that will require more than one mail server, but I'm comfortable calling them edge cases. If you have highly specialized mail requirements, then it makes sense that you should have a highly specialized mail server handling. That said, there isn't really that much difference between the simple and complex case - it's just a matter of defaults. Django needs to have a default Email backend, guaranteed available. EmailMessage.send() uses the 'default' backend - essentially just calling backend.send_messages([msg]) backend.send_messages() also exists as a direct call. SMTPConnection().send_messages() is really just a shortcut for instantiating and using an SMTP connection with the default settings. You're not compelled to use the default connection though. You could instantiate multiple instances of different backends, and use them to call other_backend.send_messages(). I see this working almost exactly as the Cache backend works right now. There is a base interface for caching. There are several cache backends; dummy and locmem are handy for testing, but if you're serious, the only one that gets used is memcached. There is a default cache instantiated as a result of the CACHE_BACKEND setting. For most people, this is all you will ever need. However, if you want to instantiate (and use) multiple caches (e.g., if you want to get really fancy about cache overflow and expiry policies), you can. > In addition, if mail backends only need to > implement one method, why not just have EMAIL_BACKEND refer to a > callable instead? Persistence of settings. s1 = Backend(host, port, username password) can be configured once, then s1 can be reused whenever needed. > I think a slightly better architecture would be this: > > * Make full use of the existing Django signals framework to send e- > mail. Have callables which implement 'send_messages()' connect to a > 'sendmail' signal through the use of a simple decorator or connector. What exactly is the use case where you need to have
Re: #10355 Add support for email backends
On Fri, Aug 21, 2009 at 8:24 PM, Andi Albrecht wrote: > > On Fri, Aug 21, 2009 at 7:23 AM, Russell > Keith-Magee wrote: >> A 'test email backend' (as well as a dummy no-mail-at-all backend, and >> a log-to-console/log-to-file backend) is a different way to target the >> underlying problem posed by #8638. > > A dummy backend/log backend sounds good. I'll add them. Is it time to > make the mail module a package? Preserving the current namespace, of > course... I think that's pretty much inevitable. Again, the cache backend is a good model here. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #10355 Add support for email backends
On Sat, Aug 22, 2009 at 1:34 PM, Andi Albrecht wrote: > > On Fri, Aug 21, 2009 at 1:45 PM, Russell > Keith-Magee wrote: >> >> On Fri, Aug 21, 2009 at 5:53 PM, Zachary >> Voase wrote: >>> >>> Hi Andi, >>> >>> On 21 Aug 2009, at 05:34, Andi Albrecht wrote: >>> >>>> Hi, >>>> >>>> I'm interested in working on #10355 "Add support for email backends." >>>> >>>> IMHO it's an good idea to make the email backend configurable. There >>>> are at least two use cases I can think of. The first is to send email >>>> with other services than SMTP, like App Engine as noted in the >>>> ticket's description. The second is to deliver email asynchronously, >>>> like the django-mailer application does already. >>> >>> I wholeheartedly agree. >>> >>>> The ticket currently needs a design decision, so my question is what >>>> the actual concerns to change this are. >>>> >>>> I would propose the following changes. It's a very simplistic approach >>>> that tries to keep the current API as much as possible: >>>> >>>> Add a new setting EMAIL_BACKEND. A string that can be resolved to a >>>> class. Default should be the current SMTP implementation. >>>> >>>> Provide a base class for mail backends. A mail backend must provide >>>> the method send_messages(email_messages) and must return the number of >>>> messages sent to provide backward compatibility. The constructor of a >>>> mail backend should take at least the keyword argument fail_silently >>>> (default: False). What I'm a bit unsure about are additional >>>> constructor arguments. Currently the SMTP backend allows in addition >>>> host, port, username, password and use_tls. Those are very >>>> SMTP-specific, but only username and password are used by the >>>> mail.send_mail* APIs. It would be an agreement to allow username and >>>> password in addition to fail_silently to not break the send_mail* API. >>>> The SMTP backend could accept host, port and use_tls as extra keywords >>>> again to provide backward compatibility for code that directly uses >>>> SMTPConnection (within Django SMTPConnection is not used outside >>>> django.core.mail). I would suggest to rename SMTPConnection to >>>> SMTPBackend, but only if this would break too much third-party code as >>>> SMTPConnection is mentioned in the docs. >>> >>> This I disagree with slightly. My main concern is the single-backend >>> architecture; many websites will probably want to use more than one >>> method for sending e-mail. >> >> I'm not sure I agree with your assertion of "many"."Some" might be >> accurate. "Your" is probably more accurate :-) >> >> I've got many websites in the field, and not one of them has needed >> anything more than trivial email handling. We've managed to get to >> v1.1 and AppEngine support is the first time that pluggable email >> backends have really been raised as an issue. >> >> This is hardly surprising. After all, email is email. You have an SMTP >> server, you connect to it, you send your mail. AppEngine is a weird >> case in that they provide an email-sending API rather than using SMTP, >> but that's an artefact of the platform. Once you have one email >> sending capability, I find it hard to believe that most people will >> need a second. >> >> I don't doubt that there are applications that will require more than >> one mail server, but I'm comfortable calling them edge cases. If you >> have highly specialized mail requirements, then it makes sense that >> you should have a highly specialized mail server handling. >> >> That said, there isn't really that much difference between the simple >> and complex case - it's just a matter of defaults. >> >> Django needs to have a default Email backend, guaranteed available. >> >> EmailMessage.send() uses the 'default' backend - essentially just >> calling backend.send_messages([msg]) >> >> backend.send_messages() also exists as a direct call. >> SMTPConnection().send_messages() is really just a shortcut for >> instantiating and using an SMTP connection with the default settings. >> >> You're not compelled to use the default connection though. You could >> instantiate multiple instances of di
Re: USStateField (again)
On Sat, Aug 22, 2009 at 7:49 PM, Tim Chase wrote: > > James Bennett wrote: >> The current proposal is for a "USPostalCodeField" which >> corresponds to the US Postal Service's list of postal codes: >> >> http://www.usps.com/ncsc/lookups/abbr_state.txt >> >> [snip] Based on the various arguments up to this point, it >> seems like no single field is going to make everybody happy, Agreed that this particular argument is a recurring theme that we should address. > Internally, I've solved a similar "can't make everybody happy" > problem with a class factory function that takes the desired set > of defined data, depending on the project: Given that the number of options is constrained, a fully-fledged factory strikes me as overkill. Why not just booleans on the field itself? USStateField(lower_48=True, dc=True, non_contiguous=True, protectorates=False, military_drops=True) No need to deprecate anything - we can continue to ship USStateField as is, just with some extra options that have default boolean values set to reflect the currently enabled choices. Given that US postal codes seems like a particularly common request, there isn't much harm in including a a USPostalCodeField as a shortcut - it's just a subclass with all the options set True. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Request for comments on patch
On Sat, Aug 22, 2009 at 9:14 PM, Manoj Govindan wrote: > > I recently came across a django ticket dealing with a pet issue of > mine. I thought of expediting the chances of a fix by writing up a > patch myself. > > Ticket: http://code.djangoproject.com/ticket/5416 > > I would like to know what experienced developers think of the patch. > Be kind, I am a newbie ;) I've just left a comment on the ticket. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: On returning appropriate subclass instances when querying a model with subclasses
On Sun, Aug 23, 2009 at 9:18 AM, Andrea Zilio wrote: > > Hi all, > > Here's what I'm talking about: > You have 3 models: Place, Restaurant and Cinema where Restaurant and > Cinema both inherits from Place. > So in the database you have some simple places, some places which > really are Cinemas and some places which really are Restaurants. > > Well, I think that this should be possible: Place.objects.all() > [, , , ] > (Current implementation only returns Places objects) ... > Maybe this has been previously discussed but I couldn't find any > ticket or any discussion about it. > So take this as a proposal if it wasn't already discussed or as a > request to have some info about the previous discussion. This has been discussed, at length, and rejected. If you search the django-dev archives, the discussion happened around the time that model inheritance was being added to the ORM. For the most part, you're looking for a series of discussions between myself and Malcolm. Using "CORBA" as a keyword in your search will help (and if you know anything about CORBA, will also explain why the idea was ultimately rejected). The techniques to achieve this sort of thing are well known and well established, but they do come at a cost. We opted not to wear that cost by default in inherited models. If you want this capability, it (or something functionally equivalent) can be added as an end-user add-on to models. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: On returning appropriate subclass instances when querying a model with subclasses
On Sun, Aug 23, 2009 at 11:00 PM, Andrea Zilio wrote: > > Great, but that wasn't exactly what I was looking for. > > What I need is a way to get the right instances from a *single* query. > > This means that I should do LEFT JOINS on direct subclasses of the > base class. > > What I need to know is if this is somehow possible without editing the > Django core, but using some signals ore something else. When I said before that it was possible to emulate this in user space, I meant you could do something like the following: * Add a klass column to your base model. * On subclasses, populate this column with a class-specific identifying value. * Add a narrow() function (naming borrowed from CORBA) on the base class that uses the value of klass to determine the subclass instance that needs to be retrieved * Whenever you need a list of subclasses, use a list comprehension that incorporates narrow: [ obj.narrow() for obj in BaseClass.objects.all() ] It's not spectacularly efficient - it does lots of joins and lots of database traffic, but it works. > Or if this is planned for some future release. As I said previously, this isn't planned for a future release - in fact, it's planned that we _wont_ do this. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #9150 needs design decision: Generic views should accept arguements for form_class
On Mon, Aug 24, 2009 at 1:40 PM, tom wrote:
>
> Hi,
>
> The form_class property for generic views such a
> django.views.generic.create_update.* should accept either a ModelForm?
> class or a ModelForm? object. This would allow generic "wrapper views"
> to easily inject run-time data into the form instance.
>
> Here is an example:
>
> def project_new(request):
> """
> A Form to create a new Project
> """
> response = create_update.create_object(
> request,
> form_class = ProjectForm,
> form_params = {'groups':request.user.groups.all(),},
> template_name = 'project_form.html',
> )
> return response
Hi Tom,
On it's own, this looks like a fine idea.
However, #9150 needs to be considered in the context of the changes
proposed by #6735: Class based generic views. This has been a
long-lived attempt to replace the single-function-with-defaults
approach with a class-based approach for defining generic views.
Moving to a class-based approach promises to make the customization
process much easier to read, (hopefully) easier to understand, and
more flexible for complex cases.
When class-based generic views land, the old-style generic views will
be deprecated. It doesn't make much sense to put development effort
into adding features when they're due to be deprecated. However, it
does make sense to ensure that the capability requested by #9150 is
included in the class-based generic views.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: On returning appropriate subclass instances when querying a model with subclasses
On Mon, Aug 24, 2009 at 9:14 AM, Andrea Zilio wrote: > > So the answer to the question "Can I get the right instances with one > single and only DB query" seems to be: > "No, you cannot do so without touching the Django orm code". > > Am I right? If, by "one single and only DB query", you mean a single Django ORM query - you are correct. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #11775 ABSOLUTE_URL_OVERRIDES doesn't work for the majority of contrib models
On Mon, Aug 24, 2009 at 5:09 AM, Jukka wrote: > > Hi all, > > I've been working with Django for a bit now, and decided to try > contributing, by submitting a patch to fix a problem I ran into at > work. This seems like something that requires a design decision. > > So, what do you think? On the whole, sounds like an interesting idea, but the patch needs a little bit of work. Comments on the ticket. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #10355 Add support for email backends
On Mon, Aug 24, 2009 at 8:47 PM, Andi Albrecht wrote: > > I've attached a patch to the issue on the tracker. The patch splits up > the mail module into a package and provides the backend functionality. > Documented functions and classes are of course available in the > top-level module. Undocumented methods like make_msgid() are not > available in django.core.mail anymore, but an additional import could > be added easily. > > Two demo backends are attached too. One implements a backend for > sending mails through App Engine's mail API, the other implements a > backend for django-mailer. In case someone is interested, I've made > the full examples of both backends available on bitbucket: > http://bitbucket.org/andialbrecht/django_mailbackend_examples/ Thanks Andi. I've left comments on the ticket. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: USStateField (again)
On Tue, Aug 25, 2009 at 11:08 AM, ch...@moffitts.net wrote: > > > > On Aug 22, 8:12 am, Russell Keith-Magee > wrote: >> On Sat, Aug 22, 2009 at 7:49 PM, Tim >> >> Chase wrote: >> >> > James Bennett wrote: >> >> The current proposal is for a "USPostalCodeField" which >> >> corresponds to the US Postal Service's list of postal codes: >> >> >>http://www.usps.com/ncsc/lookups/abbr_state.txt >> >> >> [snip] Based on the various arguments up to this point, it >> >> seems like no single field is going to make everybody happy, >> >> Agreed that this particular argument is a recurring theme that we >> should address. >> >> > Internally, I've solved a similar "can't make everybody happy" >> > problem with a class factory function that takes the desired set >> > of defined data, depending on the project: >> >> Given that the number of options is constrained, a fully-fledged >> factory strikes me as overkill. Why not just booleans on the field >> itself? >> >> USStateField(lower_48=True, dc=True, non_contiguous=True, >> protectorates=False, military_drops=True) >> >> No need to deprecate anything - we can continue to ship USStateField >> as is, just with some extra options that have default boolean values >> set to reflect the currently enabled choices. >> >> Given that US postal codes seems like a particularly common request, >> there isn't much harm in including a a USPostalCodeField as a shortcut >> - it's just a subclass with all the options set True. >> > > I'll toss out one idea. In Satchmo, we have an l10n application to > support this data. We use a fixture to load the following data: > - ISO2, ISO3 and ISO numeric > - Official Name, Continent and Aministrative Area (state, territory, > etc) > - List of all Admin Areas (aka states in US) with full name and > abbreviation > > for most of the countries of the world. > > The nice thing about this approach is that if someone wants to add an > administrative area of some sort, it can be done and if they want to > deactivate one, it's simple. I realize this may be a bit out of the > scope for this particular issue but it feels like it would be a more > robust solution and would scale nicely to other countries. This would > also be a really cool feature to have in Django as a whole. Once the > models are in place, data maintenance is pretty simple. Integrating > into the USStateField of other country fields wouldn't be too > difficult. > > Anyway, let me know your thoughts. The Satchmo l10n code is BSD > licensed and I'd be willing to help if there's sufficient interest. Hi Chris, While I can appreciate the intent of your suggestion, we've said in the past that we don't want Django to become a repository for i18n and l10n data. I don't see any particularly strong reason to change this policy. There are several reasons for this decision. Firstly, it's a lot of data to carry around, and not every project will need this data. It's also a huge maintenance burden for us - and for the translators that need to inspect and potentially translate every region name etc. Secondly, this is one of those areas where the community can play an important role. I'd much rather see a vibrant community of i18n/l10n data tools than try to generate the One True Font of Regions, and ship it with Django. Django should stick to what it is good at. Let the community decide where the best source of i18n data is to be found. So - Django tries to ship with a basic set of l10n data and tools that is useful to many. It's not perfect, but it's suitable for most simple cases. We'll try to accommodate simple configuration requests (such as giving some flexibility for US states), but there comes a point where we'll say no. There's a line between 'batteries included' and 'includes every battery you will ever need for every Tibetan kitchen appliance you will ever buy' :-) So - if you're sufficiently enthused by the l10n problem, I heartily encourage you to split the l10n code and data out of Satchmo into a separate project. If anyone else in the community is interested in this problem, I encourage you to take Chris up on his invitation to use his BSD licensed code and data. There is plenty that could be done in the l10n space for Django, and I'm eager to see what the community can do. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature proposal: Test client form value extraction
On Wed, Aug 26, 2009 at 4:41 PM, Joshua Russo wrote:
> I figured someone had done this at some time.
> What's the general consensus on when some thing like this should
> be considered to be added to the project and when it should just stay as an
> outside utility?
It's certainly worth putting up as a ticket. I can agree with the
original use case - that is, using the client.get() to construct the
prototype data dictionary that will be passed to client.post(). You
only have to look at the work that is done in the admin tests to see
the value in this proposal.
However, I have some reservations about the patch.
Most notably, I'm not sure I see how your patch answers the original
use case. The form data structure that is returned by the parser
appears to contain a top-level dictionary containing the form
instances. The form structure itself is irrelevant to reposting.
However, thats not to say that keeping the form data is irrelevant.
For example, consider the case where a page has multiple forms, or
multiple submit buttons on a single form. If we're going to introduce
a utility like this, then it should be able to behave at least
partially like a browser - that is, I should be able to get the post
data that is needed to respond to a specific button press:
response = self.client.get('/path/to/page')
# Get a copy of a data dictionary that contains the form data
# that would be submitted if I pressed the submit button labeled 'button 3'
data = response.form_data('button 3')
data['some-field'] = 'new value'
response = self.client.post('/path/to/page', data)
We also need to be careful of feature creep - this sort of testing is
exactly what Twill does, and we don't want to duplicate the efforts of
that project (or any other automated Python client test framework for
that matter).
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: App Engine support
On Fri, Aug 28, 2009 at 5:54 AM, Waldemar Kornewald wrote: > > The active contributors currently are: > * Andi Albrecht (working on email backend support) > * Thomas Wanschik (my colleague) > * Waldemar Kornewald (that's me ;) > > Since we're all busy guys who can't work full-time on this project we > could really need more contributors. It would be great to have more > Google developers on board. ;) ... > A few others have shouted, but I got no further reaction, so I don't > mention them here (please correct me and say something if I mistakenly > forgot you). To the extent that I'm in a position to provide design guidance and feedback from the perspective of the Django Core, put me on this list too. Time permitting, I might be able to contribute some code, too. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App Engine support
On Fri, Aug 28, 2009 at 6:01 AM, Waldemar Kornewald wrote: > > On Aug 27, 11:54 pm, Waldemar Kornewald wrote: >> We also have a few other potential contributors on our list, but right >> now they're too busy or not ready for contributing, yet: >> * Thomas Bohmbach (from Giftag) >> * Curtis Thompson (from Giftag) >> * Joe Tyson (maybe you know him? :) >> * Malcolm Tredinnick (core Django developer) >> >> A few others have shouted, but I got no further reaction, so I don't >> mention them here (please correct me and say something if I mistakenly >> forgot you). > > I knew I forgot someone right after having hit "Send". Sorry, was > focusing too much on App Engine. :( > > Mitch Garnaat (creator of boto) wants to help with the non-relational > backends refactoring and implement SimpleDB support. I haven't seen > any code from him, yet, but he added some info to the documentation. > His view on SimpleDB is really important for getting the non- > relational code generic enough. I hope we could get more input from > other DB users (e.g., CouchDB, MongoDB, Hadoop, ...). While I encourage you to try to find common ground between these various data stores, don't get too hung up on trying to satisfy every possible non-relational backend at the same time. A single working implementation is better than a dozen partly working ones :-) As a side note - is there anyone out of this group of AppEngine aficionados that will be attending DjangoCon? It would be good if we can use the chance for face time to sort out any big-picture issues. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: CSRF proposal and patch ready for review
On Sun, Aug 30, 2009 at 3:10 AM, Luke Plant wrote: > > Can I have some feedback on this please? ... > As far as I'm concerned, this is ready for checkin, except that I > haven't had *any* recent feedback or thumbs up etc. from the list or > other core devs. Apologies, Luke. I had this one flagged in my inbox as something to look at, and then I got distracted by other shiny objects. I've got some free time right now - I'll try to get back to you ASAP. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: CSRF proposal and patch ready for review
On Mon, Aug 3, 2009 at 11:25 PM, Luke Plant wrote:
>
> Hi all,
>
> Some big changes to the CSRF protection nearly got in to Django 1.1,
> but didn't. Since then, more work has been done, overhauling the
> whole thing really. There has been a huge amount of discussion on
> mailing lists and tickets, so I've put together what I consider to be
> the conclusions, and my proposal for a way forward, on this page:
>
> http://code.djangoproject.com/wiki/CsrfProtection
>
> That page has almost everything you need to know, but just to
> highlight some things:
>
> * The proposal is implemented in the lp-csrf_rework branch of
> this repo:
>
> http://bitbucket.org/spookylukey/django-trunk-lukeplant/
>
> The difference from trunk is regularly copied to patches on ticket
> #9977, if you want simple diffs.
>
> * The proposal (at the bottom of that page) needs review and
> consensus.
>
> * Most of the implementation has been pretty well tested, but of
> course could do with review, especially as it is security related.
>
> * The strict referer checking for HTTPS has not been tested at all
> in any live situations. (I don't have a live HTTPS site handy
> for doing such tests). It's possible that special attention also
> needs to be paid to HTTPS on non-default ports. Obviously these
> things need to be addressed before this could go into trunk.
>
> * The tutorial has not been updated. Fixing it is not trivial.
> Since we are including the CsrfViewMiddleware in
> project_template/settings.py, POST forms, such as the one in
> tutorial 4, require {% load csrf %} and {% csrf_token %}, and
> corresponding view functions (created in tutorial 3) require
> RequestContext. I don't know what to do about this. Fixing
> it is ugly, not fixing it is worse. One option is to rewrite the
> view function from tutorial 3 in tutorial 4, combining the two
> views in one -- they have a fair amount of redundant code
> anyway -- and add RequestContext at that point.
>
> I'm away for 3 weeks from this Wednesday, so I won't be able to
> respond to questions during that time. I imagine for most queries
> about the patch, 'Glenn' from ticket #9977, who has done a lot of the
> work on this (many thanks Glenn!), will be able to answer most things.
> Hopefully he's on the list!
>
> It would be best for discussion to take place on this list (or on
> ticket #9977), the wiki page is just for gathering conclusions.
I've had a quick look at the patch, and found a few minor cosmetic
things. I've also done a lot of reading of the archives to understand
why the patch is the way it is. A comprehensive teardown of the patch
will take a bit longer, but before I do that teardown, I think there's
a bigger issue that we need to address.
Are we really sure we want to do this?
Jacob flagged this back on April 1, and as far as I can make out, his
criticism is still valid. The problem is summed up by the following
question:
Are you absolutely sure that you have correctly updated all the
templates that Django ships?
You say that the update process is a simple search and replace, and
I'm sure you've been very thorough, but every form you've accidentally
missed (or overlooked because it renders the form in a strange way)
will be a regression that throws 403 errors.
Every single Django user will need to undergo the same code and
template update process. Your 'search and replace' estimate also
discounts the the engineering cost of testing and validation that we
will be imposing on every single user.
Another consequence - the external community of apps will also be
suddenly split into two - those that have been updated for CSRF
support, and those that haven't. You won't be able to use a v1.1
Django-compatible app on a Django v1.2 install without disabling CSRF
support.
One option you've mentioned is to install the CSRFResponseMiddleware
as a transition solution. This will hide the problem for v1.2, but it
will just come back to bite use when we complete the deprecation
cycle. At that point, any form that hasn't been updated will stop
working. At which point, we're back to the engineering overhead of the
update.
And all of this is dancing around the fact that the tag insertion
process is just messy. Every form template needs to import the CSRF
module. Every view with a form _must_ use a RequestContext. The
upgrade path for existing apps involves a lot of little changes. Yes,
you've documented the transition, but every extra step in a transition
document is one more thing that can (and will) be misinterpreted or
misunderstood by somebody. There's just too many moving parts involved
here for this to be a painless transition for everyone.
I completely agree that CSRF protection is important, and it's a
crying shame that the CSRF middleware is off by default. As Simon
mentioned early on, this probably means that the CSRF middleware isn't
getting used anywhere near as often as it should.
I also follow the logic that le
Re: App Engine support
On Mon, Aug 31, 2009 at 2:54 AM, sjtirtha wrote: > > Hi, > > From this point of view, I would propose, to make a new Model that > supports non SQL DB. > So developer can decide whether they want to store the object in SQL > or in non SQL DB. There are two problems here: 1. You want Django to be able to talk to non-SQL backends 2. You want to be able to talk to two different backends in the same project. Point 1 is the task of the non-SQL backend work. Point 2 is the task of the multi-database support work that Alex Gaynor has been working on for the GSoC. There's no need to conflate the two problems. The multi-db interface that Alex has been developing will allow one database to be Postgres and a second to be MySQL; once there is support for non-SQL backends, it will be trivial to make the second database CouchDB, or any other supported backend. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App Engine support
On Mon, Aug 31, 2009 at 2:48 AM, sjtirtha wrote: > > Hi, > > I'm starting using CouchDB with Python. > Django db models always work with Queries. I can understand this, > because SQL is a query language. > However, the non sql DBs do not always have the concept of queries. > For example, in CouchDB all CRUD operation is process via HTTP > request. > Create operation: PUT request > Read operation : GET request > Update operation: POST request > Delete operation: POST request (I'm not sure about this, CMIIW) > > So using the class or function name Query to access non sql DB will > not suitable. > How about to make it more general by using term Request or Operation? Why, what a lovely bikeshed. Seriously, of all the problems we have to deal with, the _name_ of the Query class isn't one of them. > I looked into django/db/models/query.py, the insert_query function > implementation is very specific for SQL. Yes. That's why we're embarking on a project to make it - and all the other SQL specific parts of the generic interface - non-SQL specific. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App Engine support
On Sun, Aug 30, 2009 at 8:52 PM, Waldemar Kornewald wrote: > > On Aug 28, 1:49 am, Russell Keith-Magee > wrote: >> To the extent that I'm in a position to provide design guidance and >> feedback from the perspective of the Django Core, put me on this list >> too. Time permitting, I might be able to contribute some code, too. > > Awesome. Could you please provide some feedback on Andi's latest patch > (or commit it if it's good enough)? > http://code.djangoproject.com/ticket/10355 > > Thanks a lot! I've already given Andi a review of his first draft; his second draft is on my list of things to look at. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: CSRF proposal and patch ready for review
On Mon, Aug 31, 2009 at 8:45 PM, Luke Plant wrote: > > Thanks for your response Russell: > >> I've had a quick look at the patch, and found a few minor cosmetic >> things. I've also done a lot of reading of the archives to >> understand why the patch is the way it is. A comprehensive teardown >> of the patch will take a bit longer, but before I do that teardown, >> I think there's a bigger issue that we need to address. >> >> Are we really sure we want to do this? >> >> Jacob flagged this back on April 1, and as far as I can make out, >> his criticism is still valid. > > I presume you are referring to Jacob's message on Apr 1 on this > thread: > > http://groups.google.com/group/django- > developers/browse_thread/thread/c23f556b88cedbc7?pli=1 That's the one. > I replied to his criticisms, which were not all correct at the time, > but didn't receive a response, so I don't think it's fair to say his > criticism is still valid. I won't presume to speak for Jacob, but my reading is that his core complaint - that the proposal as it stands is messy and will require a serious upgrade effort for every single Django user - is still accurate. True, his comments had a particular focus because of the v1.1 deadline, and some of the details about exactly what would be broken and how it would break are a little off, but I don't see that you've addressed his core complaint. >> The problem is summed up by the >> following question: >> >> Are you absolutely sure that you have correctly updated all the >> templates that Django ships? > > I'm not foolish enough to say "yes" here. I've been as thorough as I > can be, and I checked all the view functions as well as templates. ... > I can't think of a easy way to fix this. The only proper way is to > migrate *all* tests of view functions to something like twill. I'm not sure this is something we _can_ fix. Predicating a change on the assumption that the community has comprehensive test suites for their code is... optimistic at best. >> Another consequence - the external community of apps will also be >> suddenly split into two - those that have been updated for CSRF >> support, and those that haven't. You won't be able to use a v1.1 >> Django-compatible app on a Django v1.2 install without disabling >> CSRF support. > > That's not really correct - a Django 1.1 app can be run on Django 1.2 > by using the CsrfResponseMiddleware (as before), and it will work > fine. What you can't do is use an app that has been updated to use > the 1.2 CSRF template tag on 1.1. I agree that this is a serious > consequence, because once an app is updated for 1.2, it forces users > of that app to upgrade to 1.2. But that is true of any app that uses > a feature only found in 1.2. The difference here is the size and scope of the change. Consider a recent feature addition - aggregation. * Some projects will adopt the feature straight away and use it throughout their code. These projects need to put up a prominent "1.1 only" sign. * Some projects will adopt it in certain locations in their codebase. For example, they might add a 'summary' view that can be deployed. In this case, you can continue to use the entire app with Django 1.0 as long as you don't use the summary view. * Some apps will never have a use case for aggregation. These projects will continue to work with Django 1.0 as long as they don't use the new feature. In the case of CSRF, the change is to Forms. Not some small or obscure feature of forms, but the fundamental way that forms are handled. There won't be too many Django plugabble apps that don't have a form in them, and every single one of them will fall into category 1 - the "1.2 only" category. Ok, this is mitigated by the CSRFResponseMiddleware workaround, but that just defers the problem to v1.4. My point is that this is a _big_ change. It's the sort of change that I might expect to see in a 1.X->2.0 transition, not in a minor point release. >> One option you've mentioned is to install the >> CSRFResponseMiddleware as a transition solution. This will hide the >> problem for v1.2, but it will just come back to bite use when we >> complete the deprecation cycle. At that point, any form that hasn't >> been updated will stop working. At which point, we're back to the >> engineering overhead of the update. > > I don't actually see your objection here -- isn't this what > 'deprecated' means? It means you're being given warning that > something is going to stop working in the future, but you have time to > fix it now. This is true of any feature we deprecate - it will cause > engineering overhead eventually, and the cycle exists so that people > won't simply refuse to upgrade to 1.2. True, but we aren't deprecating some obscure function on the forms framework here and replacing it with a slightly different definition that requires a 1 line fix. We're effectively deprecating the way you write forms. >> However, I'm just not convinced that what we're left with is
Re: #10355 Add support for email backends
On Wed, Sep 2, 2009 at 6:46 PM, Mat Clayton wrote:
> I'm sure you have this covered but thought I would throw it into the mix. We
> are currently having lots of problems with blacklisting and spam filters
> blocking our email servers, one way we are investigating to avoid this is to
> outsource the email sending to trusted 3rd party services. We don't send
> unsolicited email (believe it or not), but being a social site, we send a
> fair amount of opt in emails, and for some reason this seems to be having an
> impact on our registration confirmation emails getting blocked which is a
> real problem for us. Something like this mail backend system seems an ideal
> solution to allow us to try and test alternatives. Just thought I would
> raise this as another reason why a pluggable backend would be a good idea,
> it would certainly help in situations like ours.
I'm not sure that this is the same problem.
The goal of having pluggable email backends is to allow for mechanisms
other than SMTP for sending mail. The main driver for this is to
support AppEngine, but there are also benefits when testing.
The situation you are describing is where you have multiple mail
servers, but they're all SMTP. In this case, you're still only using
one backend - you just have different configuration parameters
(hostname, port, password, etc).
I presume the change SMTP server is something you need to be able to
do without restarting the server or updating settings. If this is the
case, this is already supported by instantiating multiple
SMTPConnection instances. The logic required to pick the right
SMTPConnection is something you would need to code yourself, as it
would be entirely site dependent. Having multiple backends won't help
you here - with Andi's code, all you will be doing is using
get_connection('smtp') to instantiate a connection, rather than using
SMTPConnection directly.
The backend framework that has been proposed would allow you to write
a 'server-shifting backend' - that is, an email backend that
instantiates other email backends. This isn't really any different to
what you can do right now, except that it allows you to use the
send_mail() shortcut as well as EmailMessage().
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: backend query_class() question
On Wed, Sep 2, 2009 at 2:44 PM, Waldemar Kornewald wrote: > > Hi, > why does the backend's query_class() function get the default query > class as its parameter? Can't the backend just import BaseQuery? I'm > asking because with different BaseQuery implementations (for SQL and > non-SQL) there is no real default query class, anymore. I'll be the first to admit that the Query/BaseQuery/query_class() infrastruture is a little bit messy. The query_class() method on the backend exists for the benefit of Oracle. Oracle requires special handling for queries that involve LIMIT and OFFSET, as well as some custom type conversions. The reason you pass in the base class is because the Oracle backend takes the BaseQuery class, and constructs a subclass of BaseQuery that has the Oracle-specific modifications. This can't be done using simple subclassing because the InsertQuery, DeleteQuery et al are themselves subclasses of Query - or, in the case of Oracle, the generated Oracle subclass. You'll note that the only place that query_class() is used is at the bottom of sql/query.py, where the call to query_class is used to determine whether BaseQuery or a backend-generated query_class() will be used as sql.Query. This is an area of the code that is currently causing difficulty for the multi-database project. Obviously, this is also an area that affects non-SQL backends. If you have any particular requirements or design suggestions here, it would be helpful to know what they are. I was hoping to dig into this during the sprints at DjangoCon when Malcolm and I will be in the same room; the more background and requirements we have, the better. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: backend query_class() question
On Thu, Sep 3, 2009 at 4:21 PM, Waldemar Kornewald wrote: > > Also, when will your branch be merged into trunk? Is there any > roadmap? When It's Done (tm) :-) I would like to think this is on target for v1.2, but that does depend somewhat on solving one or two outstanding design issues. So, optimistically - it's on task for v1.2; realistically, I won't be surprised if it gets bumped to v1.3 > Regarding interoperability in a mulit-db enviroment, could you please > elaborate the problem? Historically, when you construct a query, parts of the final SQL query have been generated along the way - for example, parts of a where clause might be pre-computed, or column names might be evaluated and pre-quoted for safety. The final call to evaluate the SQL query pulls together all these little parts, and combines them into the final SQL call that is executed and retrieved from the database. This has been possible because we have had a single database, and so it doesn't matter when you construct the SQL - you always know the end requirements. For example, if you are using MySQL, you can assume that all column names can be quoted with back ticks. It doesn't matter if this happens during query building or query execution because the quoting behaviour doesn't change. However, when you move to multi-db, you don't know the database on which a query will execute until you actually execute the query. Any query could be tasked to any database connection, and so the query _building_ process needs to be completely SQL independent. If you built the query using MySQL assumptions, then run the query on Postgres, your column name quoting will be incorrect. So far, Alex has been attempting (and has been mostly successful) at separating the SQL building phase from the SQL execution phase. The Oracle BaseQuery issue is one hurdle that still remains. Adding non-SQL backends into the mix complicates things a little further, since a query could be directed at a non-SQL backend. Working out exactly how to handle this sort of eventuality is one of the things I want to look at during the sprints next week. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: manage.py reset and custom sql
On Thu, Sep 3, 2009 at 5:10 PM, Anssi Kaariainen wrote: > > Hello all, > > The problem I am trying to solve is this: I have defined some views > and corresponding models with managed = False. Now when I issue > manage.py reset I get an error because the views block dropping the > tables. I need to manually drop the views before I issue manage.py > reset. > > I am thinking of implementing a patch for this. This would be my first > patch for Django. The idea for the patch is simple: now there is > sqlcustom, which looks for a file in "/sql/.sql" > for each model. I would add sqlcustomdrop (better name needed?) > command which would look for sql in "/sql/ > .drop.sql". This would be run before any django generated > drop table commands would be run. > > Is there some nice way to achieve this already in Django? And is this > something that would be useful for Django core? Any feedback would be > nice before I start working on this. No, Django doesn't provide any way to do this at present. While I appreciate your enthusiasm here, and there's nothing fundamentally wrong with the design you propose, I wouldn't advise spending too much time trying to fix reset. Django provides reset mostly for historical reasons. It has some major flaws - circular cross application dependencies, for example, can completely break a call to reset. We haven't officially deprecated reset, but that's only because we aren't in a position to provide an alternative. The real alternative is a built-in schema evolution framework, and as soon as Django is in a position to add one, I would expect to see reset deprecated. Given that it is on the path to deprecation, there isn't much incentive for the core team to spend time adding features to the reset command. Suffice to say, if you're creating and dropping your tables all the time rather than using ALTER TABLE or a schema evolution framework (e.g., South or Django Evolution), You're Doing It Wrong (tm) :-) 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Final Multi-DB status Update
On Fri, Sep 4, 2009 at 7:14 AM, Craig Kimerer wrote:
> I've spent a little time using this branch and looking at the possibility of
> using it with my project. Below is a short list of problems and ponies that
> I have encountered (or want).
>
> 1. It'd be awesome if we could mark certain databases as slaves. Inserts /
> deletes / creates / drops would only run on the masters (table creation and
> deletion specifically). I can skip the slaves by passing in the databases I
> want to sync, but I still have the next issue.
So far, the implemented API is pretty low-level - it lets you direct
queries to a particular database, but the practical end-user API for
use cases such as slave/master hasn't been worked on that much. If you
go back to the original specifications, the suggested solution is to
put this in the manager, and so far I can't see any reason why this
won't work.
> 2. Only creating tables on the databases specified in 'using'. It's
> confusing (to me) connecting to a database, trying to select all my users to
> find out I am on the wrong db (because the table is empty). Perhaps tables
> should only be created on the database they are using. I don't have a good
> suggestion for this as if you were sharding data, you would want to create
> the databases on all tables that this model could potentially live on.
> Perhaps using could be be a string or list of connections,
I think this makes the third time I get to tell Alex "I told you so" :-)
I agree that this is a problem. We're still working on a solution. I'm
not sure that the Meta: using approach will be enough - consider the
case where you want contrib.auth (or some app you don't control and
doesn't specify using) to be synchronized to the non-default database.
I'm hoping to sort this out with Alex and some of the core devs during
DjangoCon.
> 3. I have multiple databases defined (some multiple times). It would be
> cool if we could 'ignore' certain databases. An example, I have 3 MySQL
> instances running. MASTER_MAIN_DB, MASTER_OTHER_DB, SLAVE_MAIN_DB. I want
> to be able to refer to them all, but also all the contrib apps I am using I
> want to live on MASTER_MAIN_DB. So in my settings I have:
> DATABASES = {'default': MAINDB_MASTER,
> 'MASTER_MAIN_DB': MAINDB_MASTER,
> 'SLAVE_MAIN_DB': MAINDB_SLAVE,
> 'MASTER_OTHER_DB': OTHERDB_SLAVE
> }
> Which means that when I run tests, it tries to drop tables on MAINDB_MASTER
> twice. Perhaps someone (Alex?) knows of a better way to do this?
Is there any reason (other than clarity) that you want to be able to
explicitly refer to 'default' and 'MASTER_MAIN_DB'? Is there some
reason that it isn't practical to just call 'default' the main-master
database and refer to it as such?
The reason I'm asking is that the duplication you are doing here will
result in you opening two different connections to MAINDB_MASTER. I
can't think of an obvious reason that this would e required. I suspect
we could work around the problem if we had some sort of aliasing in
the DATABASES definition (i.e., set up 'default' as an alias of
'MASTER_MAIN_DB'), but before we add this, I'd like to understand the
use case to see if it is worth the effort (and potential confusion).
> 4. I am using ContentTypes, and while running tests, if the default database
> is not created first, then the tests fail with an exception that the
> django_content_type table does not exist. For now I have just hacked it so
> the default table is created before any of the others. Perhaps there is a
> better way to fix this problem than that?
We'll have to look into this. Thanks for the report.
> For things like #4, where is the proper place to file a bug about that (if
> there isn't a bug already)? Do bugs from Django branches go in the normal
> tickets filed on djangoproject.com?
Yes. There is a soc2009/multidb version identifier in Trac; open your
tickets there and assign them to that version.
Yours,
Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Final Multi-DB status Update
On Fri, Sep 4, 2009 at 8:56 AM, Craig Kimerer wrote:
>
>
> On Thu, Sep 3, 2009 at 5:00 PM, Russell Keith-Magee
> wrote:
>>
>> On Fri, Sep 4, 2009 at 7:14 AM, Craig Kimerer
>> wrote:
>> > I've spent a little time using this branch and looking at the
>> > possibility of
>> > using it with my project. Below is a short list of problems and ponies
>> > that
>> > I have encountered (or want).
>> >
>> > 1. It'd be awesome if we could mark certain databases as slaves.
>> > Inserts /
>> > deletes / creates / drops would only run on the masters (table creation
>> > and
>> > deletion specifically). I can skip the slaves by passing in the
>> > databases I
>> > want to sync, but I still have the next issue.
>>
>> So far, the implemented API is pretty low-level - it lets you direct
>> queries to a particular database, but the practical end-user API for
>> use cases such as slave/master hasn't been worked on that much. If you
>> go back to the original specifications, the suggested solution is to
>> put this in the manager, and so far I can't see any reason why this
>> won't work.
>
> But if you list them in settings.DATABASES you have the problem below where
> tables try to get created on the slaves, which leads to errors because
> tables cannot be created on the slave. That was my main reason for asking
> if there was a way to skip them (I should have been more clear).
At the moment it is true that all tables are created on all databases,
but that won't be true in the final version. This ties in with my
comment on your original point 2 - we need much better ways to
describe what data is on what database. Create/Write/Read access to
that data is part of that specification.
>> > 3. I have multiple databases defined (some multiple times). It would be
>> > cool if we could 'ignore' certain databases. An example, I have 3 MySQL
>> > instances running. MASTER_MAIN_DB, MASTER_OTHER_DB, SLAVE_MAIN_DB. I
>> > want
>> > to be able to refer to them all, but also all the contrib apps I am
>> > using I
>> > want to live on MASTER_MAIN_DB. So in my settings I have:
>> > DATABASES = {'default': MAINDB_MASTER,
>> > 'MASTER_MAIN_DB': MAINDB_MASTER,
>> > 'SLAVE_MAIN_DB': MAINDB_SLAVE,
>> > 'MASTER_OTHER_DB': OTHERDB_SLAVE
>> > }
>> > Which means that when I run tests, it tries to drop tables on
>> > MAINDB_MASTER
>> > twice. Perhaps someone (Alex?) knows of a better way to do this?
>>
>> Is there any reason (other than clarity) that you want to be able to
>> explicitly refer to 'default' and 'MASTER_MAIN_DB'? Is there some
>> reason that it isn't practical to just call 'default' the main-master
>> database and refer to it as such?
>>
>> The reason I'm asking is that the duplication you are doing here will
>> result in you opening two different connections to MAINDB_MASTER. I
>> can't think of an obvious reason that this would e required. I suspect
>> we could work around the problem if we had some sort of aliasing in
>> the DATABASES definition (i.e., set up 'default' as an alias of
>> 'MASTER_MAIN_DB'), but before we add this, I'd like to understand the
>> use case to see if it is worth the effort (and potential confusion).
>
> I could do that, it was mainly for clarity. Everything inside of my app
> would specify a using of that database. No other good reason, I can move it
> over to 'default' and 'default_slave' :).
I'm yet to be convinced that `Meta: using` is actually a good thing.
IMHO, it's the very model of a setting that makes it impossible to
re-use your application. The setting will probably survive into the
final version, but I suspect we need a much better mechanism than
`Meta: using` for most common use cases. Again, this comes back to my
comment on your original point 2.
> Thanks for the response,
No problems. Thanks for taking some beta code for a spin and giving us feedback.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: patch for # 7270, select_related cannot follow reverse one-to-one relationship
On Fri, Sep 4, 2009 at 6:30 AM, Ben Davis wrote:
> Hi I've submitted a patch for this bug that I'd like to have considered for
> some trunk action... I can't take the credit for all the work on this, but
> it seems I'm taking the initiative to get it resolved.
... which is exactly what is needed. Having patches is great, but what
we really need is people willing to engage the core and the
development community over the long run to see fixes like this one
home. Persistence will be required :-)
> I really only had one question about a particular change that was needed in
> order for the .values() query to work with reverse one-to-one (e.g.,
> User.objects.values('username', 'userprofile__zip') ) . It looks like
> mtredinnick wrote the original code for this that was modified. The change
> was fairly simpe, In the setup_joins function in db/models/sql/query.py:
>
> ---
>
> raise FieldError("Cannot resolve keyword %r into field.
> "
> "Choices are: %s" % (name, ", ".join(names)))
>
>
> -if not allow_many and (m2m or not direct):
> +if not allow_many and m2m:
> for alias in joins:
> self.unref_alias(alias)
> raise MultiJoin(pos + 1)
>
>
> ---
>
> Looking at the original code, I'm not sure why "indirect" fields were not
> allowed if they weren't many-to-many relationships. This is basically what
> was keeping the reverse one-to-one lookups from working. I'm not 100% sure
> of the consequences of this change, but all model tests seemed to pass with
> this change.
>
> thoughts?
My immediate thought is that the effect of the (m2m or not direct)
logic is to remove the 'many' sides of fields from consideration. The
comparison you're looking at is operating on data that comes from line
1725:
field, model, direct, m2m = opts.get_field_by_name(name)
In this contect, 'field' can be one of 5 things:
1. Natural fields (charfield)
2. ForeignKey fields (the local end)
3. OneToOneFields (the local end)
4. ManyToManyField (the local end)
5. RelatedObject (the remote 'many' end of a FK, or the remote end of an m2m)
6. RelatedObject (the remote end of a OneToOne Field)
(1) is not of interest here. select_related() currently works with (2)
and (3). These are the values where direct=True (since they are
locally defined) but m2m is False. (4) always returns m2m; (5) and (6)
always return direct=False.
(6) is the case you're trying allow, but you can't do so at the
expense of excluding (5).
The fact that the tests don't fail when you make this change is
promising. (I presume your statement about model tests includes the
regression tests too, not just the modeltest directory) However,
there's no particular guarantee of branch coverage in Django's test
suite.
Just be sure, my suggestion here it to try and be pathological. Work
your way backwards from that if statement, and try to work out what
set of models will cause that join condition to be invoked.
Essentially, try to reverse engineer the test case that will fail if
you modify that line. If it turns out to not be possible, then explain
why; if it is possible, then you need to either find another way to
manufacture the join you need.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: proposal: decouple admin index page from INSTALLED_APPS
On Fri, Sep 4, 2009 at 7:19 PM, patrickk wrote: > > thanks for the reply. > > On 4 Sep., 13:02, Luke Plant wrote: >> On Friday 04 September 2009 10:00:37 patrickk wrote: >> >> > e.g, when I´m using djangos auth-app and I´m extending the user-model >> > with a user-profile, I´m having "auth" (with users and groups) and >> > "user" (with user profile) on my admin index page. orderd by names, >> > auth is very much on the top of my page while user is at the bottom. >> > for an editor, this is probably hard to understand (because the editor >> > doesn´t know anything about apps). for an editor, it´d more >> > comfortable having a headline "user management" with the apps "users", >> > "groups" and "user profiles". this re-arrangement could be defined in >> > admin.py. >> >> You can also define the arrangement by overriding the admin template for the >> index and hard coding in your own order. It's not ideal, but it's perhaps >> preferable to adding another place for configuring the admin. If you want >> this kind of flexibility for the index page, you might also want to add extra >> notes etc onto the page, which makes customising the template a reasonably >> good way to do it. > > yep. I know that that´s possible, but it leads to another problem: the > app-index is missing. because (referring to my initial example) "user > management" is not an app and therefore it´s not clickable. of course > I could make "user management" a link and define custom templates for > every section of my index-page. > with my proposal, "user management" would be a section containing > different apps. and either "user management" as well as every app > within this section should be clickable. > > moreover, hardcoding the index-template doesn´t seem very clean from > my point of view. > >> Having an admin.py for every project is a bit vague, because 'projects' don't >> really exist as far as Django is concerned, only 'apps'. > > I´m not exactly sure, but I don´t think that´s a huge problem, right? > maybe I used the wrong terms, but it can´t make a big difference > whether the settings-file is used for the admin or another file is > used. however, I could be mistaken. It depends :-) It is a slight problem in that we currently require no project-level code. Everything besides settings and the top-level URLconf is stored in an application. The admin app is "just another app" - there's nothing specifically "project level" about it. All the current admin registrations, for instance, occur with app-level admin.py files, and you can get very creative about those files. If you can come up with a compelling reason why a top-level admin.py file is required, we're happy to listen to it. > a bit of background information: while using djangos admin-interface > for about 3 years now, customers always complain about not finding > stuff on the admin index page. for a bigger website with about 50 apps > you get a really long list. and I just thought it would be easier if > apps are combined within sections (again, don´t nail me down on the > terms ...). On the face of it, having more ability to customize is always going to be good. The problem is, we need specificity here. So far, all we know about your proposal is that it involves a project-level admin.py. What will be in that file? How will it integrate with the AdminSite? With ModelAdmins? A project-level admin.py file isn't inherently wrong (although I must say I do share Luke's aversion to such a suggestion). However, it really depends on what you intend to put into that file. If you give some concrete suggestions, we can give some concrete feedback. Making suggestions with an eye to potential implementation difficulties (i.e., can we actually push admin to do this?) will gain bonus points. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #4926, Ordering in admin listview ignores ordering in admin options
On Thu, Sep 3, 2009 at 12:07 PM, bendavis78 wrote: > > This issue has been up with a patch for quite awhile, and wanted to > get some feedback from some devs on this. The fix is pretty simple, > and seems to work ok for me. > > Here's my thoughts on it: When I specify ordering with multiple > fields on my Model or my ModelAdmin, the changelist should respect > that ordering by default. If the user changes the ordering using the > column headers, then it should use that ordering on the single field. > I don't I see why it should only be one or the other. > > I know there's another discussion going on about adding multiple field > ordering to the UI, but that's a much bigger change. Is there any > reason why this can't make it into trunk in the meantime? There are at least 3 reasons: 1) When you make a small change that fixes 50% of the problem, you remove 90% of the incentive to fix the problem properly. 2) Implementing, reviewing, and committing a patch takes time. Time spent fixing a small version of the problem is time that could have been spent fixing the big problem. 3) Sometimes (although probably not in this case) implementing a partial solution can box us into a corner regarding potential solutions to the big problem. By implementing a partial solution, we introduce something that we need to maintain for backwards compatibility purposes. The only real reason to make an exception is if the small change will prevent data loss, or if the status-quo is fundamentally unusable. In these cases, it makes sense to implement a partial solution in the interests of correcting the breakage. However, this classification doesn't apply here. The current ordering limitations are an annoyance, but not a critical failing. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #8010: adding support for multiple test files for applications
On Fri, Sep 4, 2009 at 6:21 PM, Evgeny Sizikov wrote: > > Hi, > > I'd like the developers community to review the #8010 and the last > patch attached to the ticket. It still seems to me that it makes a > great sense and worth to make it go into the mainline Django. I echo Malcolm's comment when he wontfix'd the ticket a year ago. The patch forces a artificial naming convention. As a as a workaround for that naming convention, you proposed a glob setting. All of this seems to be in aid of avoiding one of three very simple existing solutions: * using import statements in test/__init__.py * defining a suite() that includes a test discovery mechanism that includes the tests you want * writing a custom test runner that discovers tests with a particular file prefix All three of these options are possible right now, require no code changes, and don't impose any naming conventions. I can tell you're enthused by the idea - working on a patch for a year even after it's been wontfix'd shows some serious dedication. However, that doesn't change my review - I'm still wontfix on this idea. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: proposal: decouple admin index page from INSTALLED_APPS
On Fri, Sep 4, 2009 at 8:37 PM, patrickk wrote:
>
> fair enough.
>
> I don´t have a problem with just seperating INSTALLED_APPS from
> ADMIN_APPS within the settings-file. I just thought another admin-file
> is nicer (but that´s not the key argument of my proposal).
>
> INSTALLED_APPS = (
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'django.contrib.admin',
> 'movies',
> 'stars',
> 'cinemas',
> 'games',
> 'promos',
> 'polls',
> 'festivals',
> 'trailer',
> 'user',
> 'registration',
> 'voting',
> 'django.contrib.comments',
> 'custom_tags',
> 'mediadata',
> 'stats',
> 'newsletter',
> )
>
> ADMIN_APPS = (
> (_('User Management'), {
> 'apps': ('django.contrib.auth', 'registration', 'user',)
> }),
> (_('Main Content'), {
> 'apps': ('movies', 'stars', 'cinemas', 'festivals',
> 'trailer',)
> }),
> (_('Games'), {
> 'apps': ('games', 'promos', 'polls',)
> }),
> (_('Voting/Comments'), {
> 'classes': ('collapsed',),
> 'apps': ('voting', 'comments',)
> }),
> (_('Extras'), {
> 'classes': ('collapsed',),
> 'apps': ('mediadata', 'stats', 'newsletter',)
> }),
> )
>
> if you need more details, please let me know.
Well, for starters, some clarification would help.
Are we talking about an alternate organization for models in the admin
so you're not bound to app-based categories, or are we talking about
some higher level organization?
Your example puts django.contrib.auth into the 'User Management'
collection - is that indicating that all the apps in auth should be
shown in "User Management", or that there is a "User Management"
super-group that contains the auth group that contains the auth
applications?
Your language is particularly confusing in this regard - it isn't
clear when you say 'apps' if you actually mean 'models'.
Secondly, why would this be included in settings.py (or a top level
admin.py for that matter)? Admin registrations are currently
distributed across the apps in the entire project - why is there a
need to pull this into a single location?
Couldn't this be achieved by registering a model with a particular
"app collection" (with the default being the collection formed by the
app containing the model)?
i.e., to create a "User Management" group, and put "user" in it:
class UserManagement(AdminGroup):
label = "UserManagement"
class UserAdmin(ModelAdmin):
...
class UserAdmin(ModelAdmin):
...
admin.site.register(User, UserAdmin, group=UserManagement)
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: proposal: decouple admin index page from INSTALLED_APPS
On Sat, Sep 5, 2009 at 3:32 AM, James Bennett wrote: > > On Fri, Sep 4, 2009 at 2:21 PM, andybak wrote: >> 1. I think worrying about projects vs. apps is a red-herring. We are >> talking about a way to configure an admin app. There might be several >> of these on a 'site/project/whatever' > > Since this all seems to be specific to particular instances of > AdminSite, AdminSite would be the logical place to do it if it's going > to get code-level support. However... > >> 2. Some ability to regroup and choose better names is a biggie. It >> pains me when I try and explain to my admins what 'auth' means... > > Practically everything being requested here is purely presentational. > And Django has a component for doing presentational logic: the > template system. The admin templates are deliberately easy to override > with custom versions, and it feels like all of this is really just > asking for things that are more cleanly done in templates. This isn't completely true - at least, not if you want to affect the URL structure as well. If you're just looking be able to use: /admin// and replace that with: /admin// then you need some form of representation at the code level. This can't be done purely with templates. This distinction is really only important if you want the URL structure to reflect of logical structure, rather than code structure (which, broadly speaking, is a good thing to be doing from the "URL as interface" argument). However, this use case could be handled at present with a custom site that overrides get_urls to provide the 'group' landing page, etc. I can see that providing a DSL-style way to set up these groups could be handy for a small group of users, but I can't say it's a particularly compelling use case for me personally. I strongly suspect that this could (and therefore, should) be handled as an external project in the initial phases - i.e., a "django-extended-admin' project that provides the AdminSite and ModelAdmin extensions that would make a DSL-for-groups approach possible. Patrick, Joshua - if you're enthused about this idea, I suggest you combine your efforts and try to make this external project a reality. If this external project gains traction, then we can look at merging it back to trunk. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.core.urlresolvers reverse, args and kwargs (Ticket 8764)
On Tue, Sep 8, 2009 at 12:35 PM, vegas wrote: > > Okay, so I've looked at the previous discussion on this topic, and the > code. Firstly let me say a big thank you to everyone who has worked on > Django, it's a fabulously useful piece of software, and a lot of fun > to work with. Hi Alex, Thanks for taking the time to put together this proposal. Given that you've put so much time into this, I wanted to let you know that we might be a little slow getting back to you. DjangoCon starts in just a few hours, and the people that will be in a position to give you feedback (i.e., core devs and experienced members of the community) will be a little busy for about a week. So - if you don't get feedback straight away, don't get too disheartened. I'll try to remember to get a reply to you, but if you don't have a response by this time next week, I suggest you give your thread a quick poke so that people are reminded that your proposal exists. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: backend query_class() question
On Fri, Sep 11, 2009 at 2:51 PM, Waldemar Kornewald wrote: > > On Sep 3, 4:06 pm, Russell Keith-Magee wrote: >> Adding non-SQL backends into the mix complicates things a little >> further, since a query could be directed at a non-SQL backend. Working >> out exactly how to handle this sort of eventuality is one of the >> things I want to look at during the sprints next week. > > So, what did you discuss and what were the results? :) I'll let you know as soon as they start :-) They don't kick of for another couple of hours. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: SoC merge plans?
On Sun, Sep 13, 2009 at 1:36 AM, Alex Gaynor wrote:
>
> Hey!
>
> On Sat, Sep 12, 2009 at 6:40 AM, Jacob Kaplan-Moss wrote:
>>
>> Hi folks --
>>
>> I'd like to start thinking about merging the SoC branches. As far as I
>> can tell we've got solid, worth-merging work out of all six of 'em --
>> WOOHOO! -- so let's cracking getting this stuff to trunk so people can
>> play with it.
>>
>> I'd like to ask each mentor/student pair to give me a bit of information:
>>
>> * A quick summary (more for the list than for me) of what new things
>> are on the branch, and give some instructions to people wanting to
>> review your code.
>>
>
> Multiple database support is in my branch :)
To elaborate on Alex's extensive instructions...
The multi-db branch operates exactly the same as the old code for all
current use cases.
However, if you want to have access to multiple database instances at
runtime, you can:
1) Define a DATABASES dictionary. This replaces the DATABASE_NAME etc
settings, giving a collection of database configurations, keyed by
name. Using old-style DATABASE_* settings will raise a warning.
2) Issue a query directly on a specific database:
Author.objects.using('master').filter(name='fred') => Get all the
authors named fred on the master database
3) Default models to a specific database. This is done by adding
"using = 'master'" to the Meta definition for the model. e.g., if
Author had such a definition, then Author.objects.filter(name='fred')
would be issued on the Master database.
Full docs are available on the branch.
>> * A detailed explanation of *any* backwards-incompatible changes
>> merging your branch would make.
>>
>
> If you touch anything internal to Query, it may break.
There are also changes to some of the functions on Field
(get_db_prep_* etc), but these are handled with a warning on first
use. If you have any custom fields, you will need to update these
methods to accept a 'connection' argument.
>> * Are all the technical aspects of your house in order? Is what's on
>> the branch at about the same level as we'd require from a patch (tests
>> passing, APIs complete, documentation included)? If not, what's left
>> to be done in this department?
>>
>
> We have one last DDN issue to solve and some smaller technical stuff
> to work on, Russ and I will be working on this stuff today hopefully.
Although the branch isn't ready for merge yet, the code that is
present is all up to spec. I think the sprints have produced workable
solutions for the outstanding problems; fixes implementing the
solutions we discussed should be forthcoming shortly.
There are still one or two small issues regarding usage, but I suspect
that these just require more documentation for common use cases.
>> * Is it going to be better to merge bits off the branch piecemeal, or
>> should we plan to merge the whole dang thing?
>>
>
> I technically have 2 branches. One that does multiple database, and
> one that refactors many to many relations. The latter should be
> merged before the former.
I would also add that both of these branches require some work. An
idle discussion during the sprints pointed out a possible complication
with the m2m refactor that may require some attention. The multi-db
branch is still missing a couple of features, and requires updates as
soon as the m2m refactor lands.
As an optimistic estimate, I'd guess we're maybe a month or two out
from a final review, depending on how busy Alex and myself are.
>> * Are there any other branches you're worried about comparability
>> with? Or any other sort of sequencing concerns we should take into
>> account?
The only branch that gives me pause is the model validation branch. I
haven't dug into that branch in detail, but it's possible that some of
the model level checks could intersect with some of the multi-db
changes. There is also a 'validate' method that the multi-db code has
added - we need to make sure that this API doesn't clash, either
functionally or conceptually, with any APIs introduced by the model
validation code.
Russ %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Integrating Django with Tornado's web server
On Mon, Sep 14, 2009 at 4:30 AM, Bret Taylor wrote: > > I am one of the authors of Tornado (http://www.tornadoweb.org/), the > web server/framework we built at FriendFeed that we open sourced last > week (see http://bret.appspot.com/entry/tornado-web-server). > > I just checked in change to Tornado that enables you to run any WSGI- > compatible framework on Tornado's HTTP server so that Django apps > could run on top of Tornado's HTTP server and benefit from some of the > performance work we have done. (I just sent a message to django-users@ > with getting started instructions as well, but if you are interested, > take a look at > http://github.com/facebook/tornado/blob/master/tornado/wsgi.py#L188). This is awesome news, Bret! I've only taken a brief look at Tornado so far, but it certainly looks interesting; having easy support for WSGI (and therefore Django) makes it even more compelling. > I chose the WSGI approach because it is generic and applies to all > frameworks, but Django is obviously the most widely used. I am curious > if there is any benefit to implementing more "native" support in > django.core.handlers or if WSGI is the preferred way of adding support > for new servers. If there is any performance or usability benefit, let > me know, because we would be happy to contribute our time to make it > happen. I'd be surprised if there aren't some friction points that could be optimized by using a Tornado-native interface, especially if you're looking to exploit some of the specific capabilities of Tornado. However, this leads us to an interesting chicken-and-egg situation. No offense intended to yourself and the great work you have done, but Tornado isn't a major market leader (not yet, anyway). The Django core team is very sensitive to the fact that adding something to the Django Core is effectively seen as "blessing" something as stable and worth using, and Tornado hasn't been around long enough in the public sphere to warrant that kind of recommendation. At least initially, I'd prefer to see Django-Tornado support as a project external to the Django core. It's all just Python code, after all - having a Tornado handler in the Django tree rather than somewhere else PYTHONPATH doesn't make the underlying functionality any more or less accessible. The existing mod_python and mod_wsgi interfaces could easily live outside the Django tree; they're just present as part of the 'batteries included' strategy that covers the most common mechanisms for deploying Python-based web applications at present. If, in the process of building and external Django support library for Tornado, you find that it is necessary to modify the core in order to support a particular feature of Tornado, raise a ticket in Django's Trac instance, start a discussion on this mailing list, and we'll look at making that change. This externalized approach would also be in the interests of the binding anyway. The rapid release/update schedules required by a new and emerging project aren't really compatible with an established framework like Django where the initial rapid development effort has plateaued and been replaced with a slower process of incremental updates. Long term, it may be appropriate to integrate Tornado support into the Django core, but it would be better to wait until the interface has matured before we look at integration. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: CSRF proposal and patch ready for review
On Mon, Sep 14, 2009 at 9:05 PM, Luke Plant wrote:
>
> On Monday 31 August 2009 15:26:42 Russell Keith-Magee wrote:
>
>> 3. CSRF is currently a contrib app. Why? CSRF control is the very
>> model of a feature that shouldn't be decoupled from the base
>> framework. If we're aiming to make CSRF support like XSS support,
>> surely it should be baked into the core, not kept isolated as a
>> contrib app. Is there anything else that gets easier if we sink this
>> into the core? At the very least, the tag loading issues go away - are
>> there other possible benefits?
>
> For the sake of recording my thoughts, one advantage of keeping it as a
> contrib app is that developers can completely replace the CSRF mechanism if
> they don't like the bundled one. Simply by doing
> s/django.contrib.csrf/thirdparty.csrf/ to their INSTALLED_APPS,
> MIDDLEWARE_CLASSES and TEMPLATE_CONTEXT_PROCESSROS settings,
> they would replace the CSRF mechanism (including the templatetag library) with
> their own. Their own {% csrf_token %} might return an empty string (e.g. if
> they were just using Referer checking or Origin checking or something), but
> that's fine. The admin and all other apps would then seamlessly use the
> different CSRF mechanism.
>
> So keeping it as contrib and not in core might be an advantage if some
> websites have special requirements, or the bundled CSRF mechanism becomes
> outdated.
FYI, Simon, Andrew Godwin and myself had a chance to chat about CSRF
during the DjangoCon sprints. I also discussed the issue with a few
other people over the conference.
The CSRF tag approach you have implemented didn't win a lot of fans
whenever I described it, and for pretty much the same reasons I have
expressed previously - too many moving parts, and a little too much
manual intervention required.
The discussions I had with Simon and Andrew revolved around trying to
improve the interface to SafeForm, and I think we may have a workable
solution. I've only just arrived home, so I'm fairly jet lagged at the
moment; I'll try to put the result of our discussions into the form of
a formal proposal over the next day or so.
Yours,
Russ %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Strange behaviour with exclude / filter and a nullable FK
On Wed, Sep 16, 2009 at 3:19 AM, Marcob wrote: > > On Sep 15, 8:05 pm, Alex Gaynor wrote: > >> This has already been filed as a bug in Django's ticket >> tracker:http://code.djangoproject.com/ticket/10790. In the future please try >> searching the tracker before filing a bug. > > Thanks Alex, but: > 1) I searched the trac > 2) I didn't find the bug > 3) So before filing a dupe I wrote here > > Was I wrong? Checking on the dev list before opening a ticket is the right thing to do when you can't find a matching ticket on Trac and you're not sure if you've actually found a bug. However, it's usually a good idea to add a comment to your original message that says "I've searched on Trac but can't find anything that matches". This tells us that you have tried to do the right thing, so it's a simple matter of an unsuccessful search, rather than someone who has ignored the FAQ, etc. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: SoC merge plans?
On Thu, Sep 17, 2009 at 4:35 PM, Simon Willison wrote: > > On Sep 13, 12:52 pm, Russell Keith-Magee > wrote: >> Although the branch isn't ready for merge yet, the code that is >> present is all up to spec. I think the sprints have produced workable >> solutions for the outstanding problems; fixes implementing the >> solutions we discussed should be forthcoming shortly. > > With my cowboy hat on... what are the disadvantages to merging this to > trunk /now/ and fixing the remaining outstanding issues there? It > might make it easier to get the other SoC branches compatible with > this one (which sounds to me like it makes the most far-reaching > changes) and it would encourage the wider community to help check that > everything really is backwards compatible. > > Howdy Pardner... :-) My hesitation here is that there one of the outstanding changes is a fairly big refactor of the way the SQL backend handles queries, and I want to make sure it's right before we inflict it on the world. In particular, I need to make sure that the needs of Oracle and contrib.GIS aren't broken by the refactor. I don't want to commit the patch only to have to roll large parts of it back in the near future. To keep your inner cowboy happy - I'm not actually anticipating that much of an overlap problem with the other GSoC branches. Although the changes are fairly extensive, they are mostly with internals, and not in areas that the other GSoC branches should be touching, such as database backends, details of connection handling, use of connections by management commands. The m2m refactoring patch (which is a prerequisite for the multi-db work) could be committed now without any major problems. Yours, Russ (The lone cowboy of the West) %-) --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: CSRF proposal and patch ready for review
On Thu, Sep 17, 2009 at 3:11 PM, Simon Willison wrote:
>
> On Sep 15, 2:57 pm, Luke Plant wrote:
>> OK, I'll wait and see.
>
> Here's the code: http://github.com/simonw/django-safeform
>
>> * it requires using Django's form system. I've got plenty of views that
>> don't (e.g. anything with a dynamic number of controls). People not using
>> django.Forms are left out in the cold, or having to learn another way to do
>> things.
>
> I've covered this in django-safeform by exposing a low level interface
> to the CSRF token creation and validation routines (in csrf_utils) -
> see the readme for documentation on this.
>
>> * it's off by default. Turning it on by default will require making
>> django.forms.Form subclass SafeForm, which will almost certainly require a
>> huge and immediate upgrade effort, because SafeForm cannot have the same API
>> as Form. If it's off by default, I see no point at all in this entire
>> exercise. If we don't arrive at a point where the POST form created in the
>> tutorial is safe from CSRF, I think we've failed.
>
> My priority for this is a little different: while I would dearly love
> to see all Django applications secure against CSRF by default, I can't
> see a way of doing it that doesn't break existing apps. More important
> for me though is that the Django admin (and other reusable apps, such
> as Pinax stuff) MUST be secure against CSRF out of the box, no matter
> what the user puts in their settings.py file. If developers fail to
> protect themselves (especially when the solution is well documented)
> then at least it isn't our fault.
>
> I think this is subtly different from the XSS escaping issue simply
> because the solution to CSRF is much more intrusive.
>
>> And it will still require changes to templates, just like the template tag,
>> and it will also require changes to views, only significantly more complex
>> than simply using RequestContext. It's got at least as many and at least as
>> intrusive 'moving parts' AFAICS.
>
> The SafeForm API actually simplifies views - you go from this:
>
> def change_password(request):
> form = ChangePasswordForm()
> if request.method == 'POST':
> form = ChangePasswordForm(request.POST)
> if form.is_valid():
> return HttpResponse('Thank you')
> return render_to_response('change_password.html', {
> 'form': form,
> })
>
> To this:
>
> @csrf_protect
> def change_password(request):
> form = ChangePasswordForm(request)
> if form.is_valid():
> return HttpResponse('Thank you')
> return render_to_response('change_password.html', {
> 'form': form,
> })
>
> The SafeForm deals with the request.method == 'POST' bit, meaning one
> less conditional branch within the view function itself.
Did we discuss this bit at the sprint? I'm completely on board with
everything else, but this bit makes me nervous:
* It calls is_valid() on the form during a GET (which isn't currently
done as part of normal practice).
* It isn't possible to have any special view handling based on the
request method.
* It implies that the method of construction the form will always be
the same, regardless of whether we are GETting or POSTing. This isn't
always true - in particular, I'm thinking of the construction of
FormSets, which can use a queryset to populate the forms on GET, but
don't require the queryset on POST.
> I'm pretty happy with the SafeForm interface now that I've fleshed it
> out - it's a lot less clunky than I was originally expecting.
Another advantage that Simon hasn't mentioned - it requires no
modifications to the tutorial. We can present the basic ideas of form
handling in tutorial 4 without mentioning CSRF. We then have scope to
introduce a new tutorial on security issues, that can both educate on
the nature of XSS and CSRF attacks, plus what you have to do in order
to protect against them.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal for 1.2: built-in logging with django.core.log
On Thu, Sep 17, 2009 at 6:53 PM, Ivan Sagalaev wrote: > > Hi Simon, > > Simon Willison wrote: >> 1. We'll be able to de-emphasise the current default "e-mail all >> errors to someone" behaviour, which doesn't scale at all well. > > In a recent thread[1] on a similar topic Russel has also emphasized that > we should improve documentation about doing logging. To clarify - I think that documentation is the very least we should do. As your comments indicate, there are a lot of things you need to do in order to get logging right, so we should at the very least provide some documentation on how to do it right. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal for 1.2: built-in logging with django.core.log
On Thu, Sep 17, 2009 at 4:25 PM, Simon Willison wrote: > > I think we should add logging to Django in version 1.2, implemented as > a light-weight wrapper around the Python logging module > (django.core.log maybe?) plus code to write errors to the Apache error > log under the mod_python handler and environ['wsgi.errors'] under WSGI > (meaning mod_wsgi will write to the Apache error log as well). > > Benefits of logging as a core Django service > > > Adding logging to Django core would provide the following benefits: > > 1. We'll be able to de-emphasise the current default "e-mail all > errors to someone" behaviour, which doesn't scale at all well. > > 2. Having logging in the core framework will mean people start > actually using it, which will make it easier for people to debug their > Django apps. Right now adding "print" statements to a Django app is a > common debugging technique, but it's messy (you have to remember to > take them out again) and error prone - some production environments > throw errors if an app attempts to write to stdout. It's also not > obvious - many developers are surprised when I show them the > technique. > > 3. Logging in Django core rather than a 3rd party app will encourage > reusable applications to log things in a predictable way, standard > way. > > 4. 3rd party debugging tools such as the debug toolbar will be able to > hook in to Django's default logging behaviour. This could also lead to > plenty of additional 3rd party innovation - imagine a tool that looks > out for logged SQL that took longer than X seconds, or one that groups > together similar log messages, or streams log messages to IRC... > > 5. Built-in support for logging reflects a growing reality of modern > Web development: more and more sites have interfaces with external web > service APIs, meaning there are plenty of things that could go wrong > that are outside the control of the developer. Failing gracefully and > logging what happened is the best way to deal with 3rd party problems > - much better than throwing a 500 and leaving no record of what went > wrong. > > 6. Most importantly from my point of view, when a sysadmin asks where > Django logs errors in production we'll have a good answer for them! > > 7. As a general rule, I believe you can never have too much > information about what's going on with your web application. I've > never thought to myself "the problem with this bug is I've got too > much information about it". As for large log files, disk space is > cheap - and pluggable backends could ensure logs were sensibly > rotated. No disagreement here with any of these assertions. > Places logging would be useful > == > > - Unhandled exceptions that make it up to the top of the Django stack > (and would cause a 500 error to be returned in production) > - The development web server could use logging for showing processed > requests (where currently these are just printed to stdout). > - Failed attempts at signing in to the admin could be logged, making > security audits easier. > - We could replace (or complement) django.connection.queries with a > log of executed SQL. This would make the answer to the common question > "how do I see what SQL is being executed" much more obvious. > - Stuff that loads things from INSTALLED_APPS could log what is being > loaded, making it much easier to spot and debug errors caused by code > being incorrectly loaded. > - Likewise, the template engine could log which templates are being > loaded from where, making it easier to debug problems stemming from an > incorrectly configured TEMPLATE_DIRS setting. > - We could use logging to address the problems with the template > engine failing silently - maybe some template errors (the ones more > likely to be accidental than just people relying on the fail-silent > behaviour deliberately) should be logged as warnings. > > Most of the above would be set to a low log level which by default > would not be handled, displayed or stored anywhere (logging.info or > similar). Maybe "./manage.py runserver --loglevel=info" could cause > such logs to be printed to the terminal while the development server > is running. > > Problems and challenges > === > > 1. The Python logging module isn't very nicely designed - its Java > heritage shines through, and things like logging.basicConfig behave in > unintuitive ways (if you call basicConfig twice the second call fails > silently but has no effect). This is why I suggest wrapping it in our > own higher level interface. In the absence of specifics, this makes me a little bit nervous. The Python logging interface may be very Java-heavy and complex, but it is a thoroughly known quantity, and it houses a lot of features. I've seen several attempts to wrap Java loggers in a "nicer" interface, and every one of them ended up hobbling some of the power features of the logger. There is also the
Re: patch for # 7270, select_related cannot follow reverse one-to-one relationship
On Fri, Sep 18, 2009 at 2:49 AM, Ben Davis wrote: > I noticed this ticket is currently assigned to Malcolm; in the comments he > says it's on his list of patches to work on. It looks like the last thing > he did was set the milestone to 1.2 back in March, but haven't seen any > comments on the ticket from him since then. Is it considered fair game to > re-assign this (or mark it as unassigned so that someone else can pick it > up)? I don't want to step on anyone's feet... If the ticket had been claimed by a general member of community, the answer would be "sure, go for it". However, in this case, the question you need to answer here is a purely practical one - what benefit exists in assigning the ticket to yourself? A casual look at the ticket will reveal that you have been doing a lot of work on the ticket over the last few months, and that is a lot more informative than the official ticket assignment. Malcolm is a core developer, and while he may be in a period of low activity at the moment, the list of tickets he has assigned to himself is a good list of stuff that has been tacitly approved by someone with the commit bit. You are free to keep adding patches without assigning the ticket to yourself. You can keep discussing the ticket without assigning it to yourself. Being assigned to Malcolm doesn't stop myself (or any other core dev) from closing the ticket. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django + couchdb
On Sat, Sep 19, 2009 at 5:08 PM, Suno Ano wrote: > > Hi folks, > > I was wondering, are there any plans to support couchdb [0] as > backend/database at some point? I don't want to seem rude, but a search of very recent activity in django-developers will answer your question http://groups.google.com/group/django-developers/search?group=django-developers&q=couchdb In short: yes, there are people interested in this problem. However, the problem that is being addressed is a little broader than just simple CouchDB support - it includes providing support for integrating any non-relational datastore into Django. The AppEngine guys are being the most proactive about this, but the solution we are aiming at isn't going to be AppEngine specific. This doesn't meant that Django will _ship_ with support for AppEngine, CouchDB, or any other non-relational backend. However, it does mean that we are aiming to make it possible to write and maintain a non-relational database backend in much the same way as the MS-SQL, SQLAnywhere, and DB2 backends are maintained at present. It also requires people in the community to do the work. Standing in the distance and saying "hey, you guys should support CouchDB" won't get the job done. We need people with CouchDB experience to guide the discussions we have and the plans that we are making. If you are that person, then I heartily encourage you to get involved. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: CSRF proposal and patch ready for review
On Fri, Sep 18, 2009 at 6:09 AM, Luke Plant wrote:
>
> Hi Simon,
>
> OK, here is my response. I hope this doesn't turn into a personal my-code-vs-
> your-code match (especially as most of "my code" is really other people's code
> and ideas :-) but I want to make sure we do this right, as it potentially has
> big implications, so the following will be "sleeves rolled up" (getting into
> details) and "gloves off" when it comes to criticisms of the code itself :-)
Completely understood, and right back at you :-)
> Advantages of SafeForm
> --
>
> I can see the value of having contrib apps secured whatever the user has in
> their settings.py
>
> Unfortunately, that is the only advantage of any significance that I can
> see. And there are *much* easier ways to achieve that goal if that is our
> main priority (see the bottom of my e-mail for details).
>
> There is the 'advantage' that Russell mentioned of not having to touch the
> tutorials. This is a pretty dubious advantage IMO because it means that the
> tutorials will still lead to insecure code. Far from 'raising the profile' of
> CSRF as Simon rightly suggested we should do, this is just keeping quiet about
> it.
The "advantage" here is a pedagogical one. When we're writing a basic
introductory materials, you want to avoid introducing unnecessary
details. Every time you say "don't try to understand this bit, just do
it", you introduce a conceptual magic wall that you have to break down
later. IMHO, there is some advantage to being able to defer the
discussion of building CSRF safe forms until you are explicitly
discussing security issues.
That said, it's a fairly minor advantage as long as the changes
required on the end user are also minor. If all we need to say is "put
this template tag in your form for security reasons - we will tell you
why later" then I'm not so concerned with this particular problem.
However, as the size and scope of the ignored parts become more
involved, my pedagogical objections grow.
> Disadvantages of SafeForm
> -
>
> 1) Big changes are required to use it.
>
> The changes to use SafeForm are much more intrusive than using the template
> tag. It requires quite extensive changes to both templates and views:
>
> * different API and different flow control for SafeForm compared to Form (it
> may be better, but it's different, which means a big upgrade cost)
> * a decorator for views
> * a decorator for forms
> * quite commonly, significant changes to the template:
> * Often you have to explicitly add the csrf token field. And you've
> got to worry about whether you need to or not.
> * If you weren't displaying form.non_field_errors before (which can be
> common if you don't need it), you have to add it.
> * For the multiple forms in a case, you've got even more changes
> to your view function and your template, and you have to learn about
> CsrfForm on top of everything else.
>
> Using SafeForm is a *lot* more complex than the template tag method. The
> basic instructions for day-to-day usage of the template tag method (i.e. not
> including change-once settings) go like this:
I will agree that SafeForm is intrusive - but IMHO it's intrusive in a
familiar way. There are a lot of changes required, but these changes
are just more decorators, forms, etc - the things that form the bread
and butter of Django development.
The template tag also requires intrusive changes - just in areas that
are less "familiar". To fully grok how the template tag works, you
need to grok the interplay of middleware, context processors, and
template tag loading - and while these are all core parts of Django,
the interplay of these components isn't part of the everyday Django
development experience.
> If the target of a is internal:
> * add {% load csrf %} to the template and {% csrf_token %} to the form
> * use RequestContext in the corresponding view.
>
> And that's it.
... once you've also got your INSTALLED_APPS, CONTEXT_PROCESSORS and
MIDDLEWARE_CLASSES set up correctly - and make sure you have, because
if you haven't you're going to get weird errors - or worse still,
accidentally disable CSRF protection.
To be clear - my concern isn't with the template tag itself. I think
that part is quite elegant. My concerns stem almost entirely from the
dance that is required to make the whole thing work right in the first
place.
That said, I think your remaining criticisms about SafeForm are
entirely valid, and I can't really offer much by way of defense. The
SafeForm approach as implemented is about as good as it will ever get
- we might be able to tinker around the edges a bit to fix some of the
issues you describe with testing, but fundamentally, SafeForm requires
that end-users use a different type of Form, and that will require
lots of code churn and the related complications you raised.
So - is there anything we do to make the template tag more palatable?
I think we ca
Re: Django error
On Sun, Sep 20, 2009 at 2:49 PM, zweb wrote:
>
> When I try to download a file through django in IE , I get
>
> [Sun Sep 20 05:34:20 2009] [error] [client 127.0.0.1] response =
> func(request, response), referer: http://www.com
> [Sun Sep 20 05:34:20 2009] [error] [client 127.0.0.1] File "/home/
> pmc/webapps/test/lib/python2.5/django/http/utils.py", line 77, in
> fix_IE_for_vary, referer: http://www..com/
> [Sun Sep 20 05:34:20 2009] [error] [client 127.0.0.1] if response
> ['Content-Type'].split(';')[0] not in safe_mime_types:, referer:
> http://www.com/
> [Sun Sep 20 05:34:20 2009] [error] [client 127.0.0.1] AttributeError:
> 'list' object has no attribute 'split', referer: http://www.com/
>
>
> I am doing,
>
> for f in range(len(filepath)):
> file_data = open('%s' % (filepath[f]), "rb").read()
> response = HttpResponse(file_data,mimetype= content_type)
> response['Content-Disposition'] = 'filename ='+ fname
> return response
>
> where content_type is same as content Type of uploaded file thorugh
> django
Two points:
1) Please don't cross post between mailing lists. Find the right forum
and use it.
2) Django-developers is not the right forum in this case.
Django-developers is for discussing the development of Django itself.
If you have a general "how do I" question, django-users is the right
place.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: #9194: Allow additional hashing algorithms for passwords
On Fri, Sep 18, 2009 at 10:29 PM, PiotrLegnica wrote: > > Hi. There is a feature described in a ticket #9194[1], which has been > marked as 'Design decision needed'. > > Is it still being discussed, or has it been forgotten completely? I'm > working on a patch for myself, but I'm not sure whether I should > attach it to ticket when I finish, if it's marked that way. > > [1]: http://code.djangoproject.com/ticket/9194 "Still" being discussed isn't really accurate - as evidenced by the level of activity on the ticket, it wasn't really discussed in the first place. Forgotten completely isn't accurate either - the ticket exists, so it hasn't been forgotten. However, this particular problem hasn't represented enough of a personal itch for anyone to drive a serious discussion of the idea on django-dev. Personally, I see this as a pretty low priority item, verging on wontfix. My usual position is that having more pluggable interfaces is a good thing, but in this case, IMHO, there isn't enough change and innovation in hashing algorithms to warrant a fully configurable interface for defining password hashes. There might even be an argument to _not_ make it configurable to discourage people from trying to write their own hashing algorithms. contrib.auth currently supports MD5, SHA1 and crypt, which IMHO covers all the important bases. If you think there is an obvious candidate that is missing, I think I'd rather see us add specific support for that algorithm rather than a pluggable interface. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.core.urlresolvers reverse, args and kwargs (Ticket 8764)
On Tue, Sep 8, 2009 at 12:35 PM, vegas wrote: > > Okay, so I've looked at the previous discussion on this topic, and the > code. Firstly let me say a big thank you to everyone who has worked on > Django, it's a fabulously useful piece of software, and a lot of fun > to work with. > > By my lights, changeset 8760 could be considered to induce a > regression. I say this because if you look at the doctests on lines > 87-92, it seems pretty clear that original author had args and kwargs > playing together happily. Whether or not anyone other than this > Killarny fellow, and myself give a rat's patoot is another story :D . Malcolm explains the state of play regarding the backwards incompatibility from [8760] in the discussion around #8764. Regardless, the changeset predates v1.0, so it isn't covered by our v1.0 backwards compatibility guarantees. > I do feel that the docs talking about urlconfs > could use a more direct approach. I'd add the following very > forthright disclaimer to > http://docs.djangoproject.com/en/dev/topics/http/urls/#topics-http-urls Any documentation suggestions are welcome, but django-dev isn't the right place. Work up a patch, and attach it to the ticket. > In terms of adding back args and kwargs playing together nicely in the > Garden of UrlDen, it would seem to me to be accomplishable by doing > the following(I'm referencing Django 1.1 line numbers here, if there's > interest in a patch I will work one up against SVN): ... > If the community is interested in regaining the capacity to have args > and kwargs in the same urlpattern I'd be happy to work up a patch > following those outlines and run it through whatever tests are > desired. I don't think you'd see any objection to a patch that allows for mixing args and kwargs - if you can find a way that (1) works in the general case, and (2) can be calculated quickly. Remember, URL dispatch is the core of what Django does, so it can't be a slow operation. I haven't done any sort of formal proof, but Malcolm is a smart guy, and my gut reaction is that he is on the money - this is something that simply isn't possible in the general case. If you want to prove us wrong, code - and the mother of all test suites - is the way to do it. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: SoC merge plans?
On Fri, Sep 18, 2009 at 5:30 PM, Waldemar Kornewald wrote: > > On Sep 17, 1:48 pm, Russell Keith-Magee > wrote: >> My hesitation here is that there one of the outstanding changes is a >> fairly big refactor of the way the SQL backend handles queries, and I >> want to make sure it's right before we inflict it on the world. In >> particular, I need to make sure that the needs of Oracle and >> contrib.GIS aren't broken by the refactor. I don't want to commit the >> patch only to have to roll large parts of it back in the near future. > > What exactly is still unclear? Are you not sure whether to have a > query_class() function or whether to override the whole query module? > Any other issues? If you dig into the code around supporting Oracle, GIS and sql.Query you will discover an interesting nest of vipers regarding the handling of the sql.Query subclasses. Untangling that nest is not a trivial operation, but it is something we need to do in order to make MultiDB work. While Alex and I have a plan, we have not yet demonstrated that the plan will work in practice. I don't want to commit anything to trunk until I know that it will work. Based on the discussion Alex and I had at the sprints, query_class() will still exist, but it will play a slightly different role - essentially, it will be more important for non-SQL backends than for Oracle support. I hope to have a chance to look at this over the next couple of weeks, but this will be largely controlled by the amount of free time I have and the level of activity on django-dev. Once we've got a solution working, I'll post something on django-dev to let people know what is going on. >> The m2m refactoring patch (which is a prerequisite for the multi-db >> work) could be committed now without any major problems. > > Then could you please commit the m2m patch? This would help us with > the non-relational branch. Thanks! The preliminary work is available on Alex Gaynors github account: http://github.com/alex/django/tree/m2m-refactor It will be in trunk as soon as I'm sure it's ready and I've got another core developer to give the all clear. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Fri, Sep 11, 2009 at 7:00 AM, Tobias wrote: > > In the spirit of Russell's No! Bad Pony! talk at DjangoCon I'd like to > start a conversation about cleaning up session messages enough to get > them into core or contrib. Alex suggested that the ticket (http:// > code.djangoproject.com/ticket/4604) was not the right place for the > conversation so I'm starting one here. > > There are a number of usable solutions out there but django-notify is > the most complete, polished one that I know of. I just contributed a > patch for combo/fallback storage, a version of which SmileyChris > integrated into trunk (of django-notify, not django). It's a solid > product with well-commented code and a good test suite. > > What needs to be done to get this or something like it into contrib? Since you were evidently at my DjangoCon presentation, you know that I (and the core in general) have a pretty high level of reticence to adding things to contrib - especially when the package can live quite happily outside of core. So far, everything I have seen about django-notify/djangoflash makes it seem like a completely standalone package that will gain nothing from being part of core, other than increasing the size of the tarball, and increasing the maintenance load of the core team. One of the questions that needs to be answered is "why should this be shipped with Django?" Packages also need to meet the basic definition of django.contrib in order to be accepted. Part of this definition is that it must be the defacto standard implementation. In order to be the defacto standard implementation of anything, it needs to be relatively stable and feature complete. When you make statements like "I just contributed a patch for combo/fallback storage", it leads me to believe that this may not be the case - at least, not yet. You also mention that there are a number of other implementations, but you haven't really given a compelling survey or analysis of the alternatives - you've just blessed one in particular. Why? Another piece of the puzzle that is missing from my perspective is any discussion of how session-based messaging interacts with the existing contrib.auth messaging framework. IMHO, Django shouldn't ship with two messaging APIs, so what is the integration point? Do we need a messaging backend API? I haven't thought about this problem anywhere near enough to offer a proposal, but I haven't seen any discussion of this point either. A good solution for this problem would go a long way to greasing the wheels. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.core.urlresolvers reverse, args and kwargs (Ticket 8764)
On Sun, Sep 20, 2009 at 10:44 PM, vegas wrote: > > Cool, will do. I guess the earliest release this could get into > would be django 1.2? > > Looking at http://docs.djangoproject.com/en/dev/internals/contributing/ > , it seems to me like this would definitely be considered a non- > trivial patch. Yes - this would be considered a non-trivial patch. > Should I work up a more readable version of my initial proposal for > discussion, or would you rather just have a patch and a bunch of > tests? It's easy to propose a solution - it's a lot harder to actually make it work. In this case, code - and, in particular, tests - will be a lot more convincing than a text description of the approach. However, be prepared for the outcome that your code may be rejected and thrown away. In this case, the code is serving as a working implementation of your proposal, and we still haven't been convinced of your proposal. Just writing the code doesn't mean it will automatically get accepted. > Are there any pre-existing benchmarks on the url resolution process? > Looking in trunk/tests, I see > http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/urlpatterns_reverse > which looks to mostly be correctness tests, not performance tests. You are correct that there aren't any performance tests. The performance test is not allowing O(2^n) algorithms into the URLresolver in the first place :-) 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven wrote: > >> One of the questions that needs to be answered >> is "why should [a session based notification system] be shipped with Django?" > >> Another piece of the puzzle that is missing from my perspective is any >> discussion of how session-based messaging interacts with the existing >> contrib.auth messaging framework. IMHO, Django shouldn't ship with two >> messaging APIs, so what is the integration point? > > Having some kind of defacto cross-request notification system makes > sense; it's a very common usage pattern. > Attaching these kind of messages to a User instance is wrong: there is > not an enforced one to one correlation between a user and a session > [1], and you can't notify anonymous sessions. > > The current contrib.auth messaging framework can't be removed or > replaced while keeping full backwards compatibility. A basic user > based messaging system still has it's uses, but it is not the best fit > for session notifications. > Side note: a pet peeve of mine is that contrib.auth messages are not > lazily loaded, which means you get a db hit every request [when using > a RequestContext] and lose your messages whether you use the messages > context var or not, but this is a side issue and should probably be a > ticket of it's own. > > For some background, I initially started 4604 much more tightly > coupled with core, and one which backwards-compatibly worked with the > current user-based messaging system. Malcolm specifically requested > that this should be written as a stand-alone contrib app rather than > part of core, and that it should have minimal impact on existing code. Sorry - perhaps I need to be more clear on my intent here. I'm convinced of the importance of session-based messages - just not of when and how a particular implementation should be added to trunk. I agree that they are a useful idea. I agree with Malcolm that session based messages should be a standalone app. I don't think they should be tightly bound to core. What I'm talking about is an orthogonal set of modifications that would allow for _any_ messaging system (database backed, session backed, or magic pony backed) to be used. This doesn't couple a particular implementation of session-based messages to the core, but it would allow for end-users to choose a session-based message framework if they found one that was appropriate to their needs. In the fullness of time, we may end up adding django-notify or similar to contrib, but if we add the plugable backend we can defer that decision until much later when implementations have stabilized and a clear implementation winner has emerged. If such an abstraction API isn't possible (and the differences between the capabilities of the two certainly makes this likely), then that makes it even more important that we choose the right implementation to add to contrib. As it stands, I'm aware of at _least_ two implementations (django-notify and djangoflash), but I have no real feel for the implementation maturity or general level of community acceptance of either. I'm not going to advocate adding anything to contrib until I can be convinced that one particular implementation really is the defacto standard implementation of the pattern. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Looking for a project
On Sun, Sep 20, 2009 at 11:29 PM, Daniel Watkins wrote: > > Hello all, > > As part of the third year of my computer science degree (at the > University of Warwick), I need to complete an individual project. I'd > quite like to use this to do something for Django. The project is meant > to be done entirely individually, which means that something that works > as a standalone app (rather than being a branch of Django itself) would > be preferable. > > The project needs to be completed between the beginning of October and > April, with about 5 hours a week being spent on it. > > I have a few half-formed ideas of my own, but if anyone else has an idea > of what I could do, I'd like to hear about it. First off - this sort of question would be better suited if you asked on Django-users. Django-dev is for discussing the development of Django itself; django-users is for general user queries. Admonition aside: it might help if you narrow the scope of your question for us. This is for an academic project - what constraints is the university placing on the project? Do you need to demonstrate technical competence in some particular area? Do you want/need to use any particular set of technologies? Is project planning and management more important than technical issues? Depending on your exact project needs, there are any number of options available. 1) Build a pluggable app that implements some interesting piece of functionality. This seems to be where you are focussed at the moment - build a pluggable application that implements some useful feature, such as webmail or a calendar. There are any number of options here; my only advice is to make a good survey of the state of the art before you try to duplicate an existing project. The apps integrated with Pinax are probably a good place to start looking. It may also be worth asking the Pinax guys to see if they have any wishlists for new apps. This sort of project is good if you're looking to prove high-level web programming skills plus JS+HTML. 2) Implement something that is a standalone feature request for Django. You could also look at utilities that would be useful to Django without actually being part of Django itself at present. For example, there is a long standing feature request to allow for more customization in the serializers. If your design and code is good, it might eventually end up in the Django core, but in the interim, you could tackle this as a standalone project. This sort of project would be good if you need to prove API design skills, and want to stick to Python as an implementation language. 3) Implement a backend for one of Django's public APIs. Django exposes a number of backend APIs that are designed for end-users to extend. For example, consider the database backend. IBM DB2, MSSQL and SQLAnywhere are all supported as external projects with no involvement or interaction with the Django core. So which backend to implement? Well, at this point, we have all the common relational databases covered, but we don't have a good answer for non-relational databases. We have someone working on the Google AppEngine backend at the moment; if you were to pick another datastore (say, CouchDB, Cassandra or MongoDB), you could use the get up to speed with an emerging web technology, plus be contributing in a meaningful way to the Django community, without actually working on the Django core itself. This sort of project would be better suited if you need to prove capabilities in low-level technologies and APIs. However, it might also be a little ambitious given your time constraints. You'll have to judge this one for yourself. So - there are lots of options. It really comes down to what you're interested in, and what you're trying to achieve with your project. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: SoC merge plans?
On Mon, Sep 21, 2009 at 4:28 PM, Waldemar Kornewald wrote: > > On Sep 20, 1:54 pm, Russell Keith-Magee > wrote: >> Based on the discussion Alex and I had at the sprints, query_class() >> will still exist, but it will play a slightly different role - >> essentially, it will be more important for non-SQL backends than for >> Oracle support. > > Could you please explain what you have in mind, so I can comment on > it? While I appreciate the enthusiasm, I need to repeat what I said originally - this is a fairly big refactor of the way the SQL backend handles queries, and I want to make sure it's right before we inflict it on the world. This includes abstract discussions of what might be. Give me a chance to flesh out the ideas that I have and make sure that they work for the problems we already have (Oracle and GIS). Once I'm sure we have got those issues under control, we can tackle the new problems like supporting non-SQL backends. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: CSRF proposal and patch ready for review
On Sun, Sep 20, 2009 at 2:57 AM, Luke Plant wrote:
>
> On Saturday 19 September 2009 16:56:52 Russell Keith-Magee wrote:
>
>> On Fri, Sep 18, 2009 at 6:09 AM, Luke Plant wrote:
>> > If the target of a is internal:
>> > * add {% load csrf %} to the template and {% csrf_token %} to the form
>> > * use RequestContext in the corresponding view.
>> >
>> > And that's it.
>>
>> ... once you've also got your INSTALLED_APPS, CONTEXT_PROCESSORS and
>> MIDDLEWARE_CLASSES set up correctly - and make sure you have, because
>> if you haven't you're going to get weird errors - or worse still,
>> accidentally disable CSRF protection.
>
> Fair point - I was explicitly talking about the *day-to-day* usage at that
> point. For the other things, the errors aren't quite so inscrutable any more
> - the 403 page looks like this now:
>
> http://lukeplant.me.uk/uploads/django_csrf_403.html
I agree that this makes the reasons a lot clearer, but I stand by my
criticism that it's still a metric buttload of instructions just to
make a basic form submit.
My concern here is that every time you add an item to a list of
migration instructions, you increase the possibility that something
can go wrong. In turn, this increases the likelihood that a potential
convert will get frustrated and declare that "Django sucks" - or
worse, that an existing convert will declare "WTF" and go somewhere
else. In this case, the thing that is going to go wrong is "submitting
forms", which is pretty much the bread and butter of a web framework.
IMHO, anything we can do to limit the number of things that can go
wrong, the better.
> ...but is it really our fault if people disable the protection? I guess to the
> extent that we've made it difficult to get right, or more tempting to do it
> wrong, it *is* our fault.
I'm not sure that this is a distinction that users are going to make
when their site gets hacked. I would bet money that regardless of the
cause, Django will wear the blame. If the problem was caused by the
end user disabling CSRF protection against Django's advice, then it
will be Django's fault that it was possible to disable it at all.
>> So - is there anything we do to make the template tag more palatable?
>>
>> I think we can - and you've already shown how:
>> > In fact, if you simply want to fix contrib apps, SafeForm is a massively
>> > over- engineered solution, as there are *much* less invasive ways to do
>> > it. All you need to do is:
>> > 1) add the CSRF template tag to builtins and use it in templates.
>> > 2) add a @csrf_protect decorator on views.
>> > 3) hack RequestContext so that it always includes the CSRF context
>> > processor.
...
>> >
>> > All contrib apps use RequestContext anyway, so the changes needed for
>> > that method would be tiny, with no changes to settings.py required.
>
> OK, I agree that this solution has some nice features, but let's be realistic
> about its failings:
>
> 1) changing RequestContext so it always includes the CSRF context processor is
> ... 'cowboy', as I think Simon would put it :-) I wasn't actually suggesting
> that as a real proposal.
I was :-) Or rather, I'm not thinking about this as an 'always
included context processor', but as a core piece of functionality that
we should bake into RequestContext. CSRF is a very big problem at the
core of rendering forms. Why not make CSRF protection a core part of
the RequestContext contract?
> 2) We would still have to fix all the tests, because we can't just turn the
> decorator off. There are also the tests that we can't fix, i.e. where other
> people have customised contrib apps in various ways and written tests against
> the views. I mentioned this in my most recent reply to Simon. I'm not so
> bothered about having to fix ours, it's other people's that worry me, and
> the DRY violation - baking it in like this means that every test of a POST
> view is now concerned with CSRF.
>
> I can think of some hacks to avoid fixing tests (ours and other peoples):
Agreed that we shouldn't require wholesale updates to test suites.
The test suite already does some setup/teardown to make a testable
environment - for example, swapping out the SMTP outbox - removing or
mocking CSRF protection could easily fit into this box.
> I think the lazy instinct which makes me not want to fix even our own tests is
> a healthy instinct at root...but I don't know how to address it best.
Agreed, on both counts.
> Seriously, another option is to make AdminSite.check_dependencies require the
> middleware. It already
Re: CSRF proposal and patch ready for review
On Tue, Sep 22, 2009 at 10:34 AM, Luke Plant wrote: > > OK, you convinced me. I really would rather this wasn't baked in, but given > the migration issues and the fact that it is security related, I guess I can > stomach it. > > I've updated the patch [1] to move things to builtin functionality. I also > had to fix some bugs to get the csrf_protect decorator working for methods, > which are in trunk already. > > I've left most of the code itself under django/contrib/csrf because: > > 1) backwards compatibility with people importing the middleware > means we have to leave django/contrib/csrf for some things > anyway. > 2) In this case, I don't see any great advantage in having stub modules > which just import other stuff for backwards compatibility This isn't just a "moving deckchairs on the Titantic" thing - I can think of at least three good reasons we should be moving the code into core modules: * Maintaining the basic contract of django.contrib - that you should be able to delete the contrib directory and have Django still work. If all the CSRF code is in contrib, this won't be the case. * Making it clear that this really is a core feature - it's a core template tag, a core middleware, and a core context. Just like the URL is part of the UI for a web app, the module namespace is part of the UI for a library like Django. * For deprecation purposes, we can say that the whole contrib.csrf module will be deprecated in 1.4 (at which point, CSRF will be an entirely core feature). > 3) I really can't be bothered to change all the imports > at this point in time! I can understand this as interim measure while we get consensus with other core developers, but I'd be -1 to leaving the code as is for the final commit. > I moved the template tag itself to core code, because it was causing import > cycles otherwise, and there are no backwards compatibility issues, nor does it > add any actual imports of contrib code to core. Which reinforces the point. Some of the code is going to be in core. Do you want to write the documentation explaining why some code is in contrib and some isn't? > I think the patch now addresses all your/our concerns: Agreed. > I fixed the tests by a custom attribute on request objects that tells the > middleware/decorator to not actually reject requests. This is better than > disabling completely, because it means that the middleware will still send > cookies etc., and it's always good to have tests as close as possible to the > real code. The test client adds the custom attribute to HttpRequests after it > has created them. I had to add the attribute in one other place in the code > as well - a test that was manually calling a view function that had > csrf_protect applied. > > This method of fixing tests was also the best for testing the CSRF middleware > - globally mocking the middleware out would have made it hard to test the > middleware itself! I'm reasonably happy with the testing approach you've taken - or, at least, I can't think of anything substantially better. My only comment is that we might want to put an underscore on the magic variable (i.e., request._dont_enforce_csrf_checks) to reinforce the fact that this really isn't public API. > Docs are all updated, all tests passing etc. > > If people are happy for this to go in, it would be very helpful if other > people could have a go updating their apps and give the general docs/upgrade > instructions/tutorials a good check after I commit it. I can't easily do > checks like that, because I just won't spot the holes after having the code in > my head for so long. Whew. Well, that was a year well spent :-) At this point, I'm convinced, mod the minor things I've flagged. However, I'd like to see Jacob and Malcolm chime in before this is committed. > The only thing left is a nicer render_to_response shortcut for using > RequestContext, which is a refinement we can add later. Agreed, and it's a mostly orthogonal change anyway. Russ %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Wed, Sep 23, 2009 at 1:55 AM, Tobias McNulty wrote: > Vaclav, > I think this is less of an issue, because you'd have to switch to another > tab and perform a second operation that generated feedback in the ~200 > millisecond window of time between clicking a link and the new page loading. Ah... the wonderful American perspective of the internet. :-) As a proud resident of the antipodes, allow me to assure you that 200ms is not a representative sample of the time required to load a page for those of us that don't live in the continental USA. Let's consider Rackspace as a representative sample of a US based server with plenty of bandwidth. As the crow flies, I'm about 17000 km from a server in Texas. By simple laws of physics, it takes 60ms for the signal to get from me to the server, and 60ms for the signal to get back. That's 120ms, and I'm not even taking into account: * The time spent going through the 14 routing points between me and Rackspace's servers * The fact that the cable between me and Texas doesn't follow the same route as a crow In reality, I get a ping time closer to 300 ms. And that's to a high-end data center under ideal conditions - it can be much larger if I'm dealing with low end providers. Now add the time required to actually compute a response. To put this in practical perspective - during DjangoCon, I heard lots of people complaining about the speed of the hotel wireless network. I didn't notice a serious change from what I use at home every single day. In this particular case, I think you're correct - I'm not especially concerned about parallel cookie requests. However, there are plenty of arguments that get made on the assumption that the internet is a form of instant communication ( database connection lag ). I want to drive home the point that Earth is a very large place, and no matter where you are located, most of the world's population isn't anywhere near you - and no amount of technology will fix problems caused by the laws of physics. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: How to customize field to get the correct python value?
On Fri, Sep 25, 2009 at 10:40 AM, Jay wrote: > > Hi there, > > I have a question on customize the db field. For this field, I want to > save integers in db, but want them to be my custom class when they are > used in Python code. In Django docs, it's said that I should set the > __metaclass__ to be models.SubfieldBase to make to_python() work. I > tried it and succeeded when all data of one db row are fetched. > > But I then found that if I use query method like values(), values_list > () or only(), the data of my custom field will not be converted into > my desired type but the raw db integer. Then I tried Django's own > DateField, it works OK also in such scenario. So I think there must be > something I missed. > > Could you help on this question? I cannot find more materials to move > on, so I'm very eager to get your help. Many thanks! Two points: 1) Please don't cross post messages to multiple mailing lists. Find the right forum, and ask once. 2) Django-developers is not the right place. This mailing list is for discussing the development of Django itself, not answering general user queries. Django-users is the list you want. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Adding signing (and signed cookies) to Django core
On Fri, Sep 25, 2009 at 1:18 AM, Simon Willison wrote: > > As mentioned in the thread about cookie-based notifications, at the > DjangoCon Sprints I raised the subject of adding signing (and signed > cookies) to Django core. > > I've found myself using signing more and more over time, and I think > it's a concept which is common enough to deserve inclusion in Django - > if anything, its use should be actively encouraged by the framework. Put me down as +1 in favor of adding support for signed cookies in some form. As for the exact form that the API will take - I don't have any particularly strong opinions at this point, and there are plenty of big brains weighing in, so I will stay out of the discussion and let the community evolve the idea. By way of greasing the wheels towards trunk: if the outcome of this mailing list thread was a wiki page that digested all the ideas, concerns and issues into a single page, it will make the final approval process much easier. Luke Plant's wiki page on the proposed CSRF changes [1] is a good model to follow here - I wasn't involved in the early stages of that discussion, but thanks to that wiki page, I was able to come up to speed very quickly and see why certain ideas were rejected. [1] http://code.djangoproject.com/wiki/CsrfProtection 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.template refactoring (again) #7806
2009/9/26 Аркадий Левин : > > Pong. OK - that is rude and complety uncalled for. Johannes has gone to a lot of effort to make a complex proposal; if you aren't going to contribute back in kind, I would kindly ask you to keep your comments to yourself. Johannes - I apologize for not giving you feedback sooner. I've had this on my list of things of to look at for a while, but I keep getting distracted by other things. I will try to get you some feedback in the next day or so. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
On Sun, Sep 27, 2009 at 1:34 AM, Rob Hudson wrote: > > On Sat, Sep 26, 2009 at 2:13 AM, Simon Willison > wrote: >> Yes - I looked briefly at how much work was involved in doing this and >> it's not insubstantial, which is why I opted for string replacement >> just to demonstrate the API. I'm confident the exact functionality of >> django-html could be replicated in a less messy way by patching core, >> but it would require quite a bit of refactoring of django.forms. > > This is the bit I was hoping we could get to. What would that > refactoring look like, you think? Would it involve making forms use > Templates? Or something else? This is idea that I think has a lot of merit. Django has always had a policy of being client-side agnostic - the XHTML-specific output format has always been the chink in that armor. The impending significance of HTML5 increases the incentive to have this debate (and more importantly, to get it right). If this requires changes to the way forms and fields are rendered, I'm happy to entertain those ideas, as long as they retain backwards compatibility. However, as with the signed cookie discussion, I don't have any particularly strong opinions on the exact form that the API should take, so I will stay out of the discussion and let the community evolve the idea. By way of greasing the wheels towards trunk: if the outcome of this mailing list thread was a wiki page that digested all the ideas, concerns and issues into a single page, it will make the final approval process much easier. Luke Plant's wiki page on the proposed CSRF changes [1] is a good model to follow here - I wasn't involved in the early stages of that discussion, but thanks to that wiki page, I was able to come up to speed very quickly and see why certain ideas were rejected. [1] http://code.djangoproject.com/wiki/CsrfProtection 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.template refactoring (again) #7806
On Fri, Aug 28, 2009 at 9:41 PM, Johannes Dollinger
wrote:
>
> The proposal and motivation are essentially the same as in the last
> thread [1] and the ticket description [2]. I put it on the 1.2 feature
> list.
> I tried to split my patch into smaller, more readable commits here:
> http://github.com/emulbreh/django/tree/master
> I haven't converted defaulttags, loadertags and django.templatetags.*
> yet to show that it's (mostly) backwards compatible (see below). It
> would be useful to decide on some questions in the "API Design .."
> section below first.
>
> I'll summarize the core ideas again as well as problems and pending
> design decisions.
>
> Concepts: Expressions and TokenStream
> =
> Variable and FilterExpression will be deprecated as they require the
> caller to know the length of the expression in advance.
I'm not sure I follow this assertion. I have no problem believing
FilterExpression can be made cleaner, but Variable takes an expression
like 'article.section', plus a context, and resolves it into a string.
In itself, it seems like a well built and stable piece of API.
> This makes
> whitespace handling cumbersome and some syntactical constructs really
> hard to parse (e.g., the {% url ... %} parser is broken by design).
Saying {% url %} is "broken by design" doesn't accurately represent
the problem - it was a victim of inadequate tag building tools, and
now can't be fixed due to backwards-compatibility guarantees.
> Variable vs FilterExpression
> ==
> I could only find documentation for Variable. If the internally used
> Parser.compile_filter() is indeed undocumented there is no official
> way to use FilterExpression in custom tags. If that means that
> FilterExpression.resolve() behaviour doesn't have to be backwards
> compatible, that would help a lot ..
As best as I can make out, you are correct. FilterExpression appears
to be an internal, so isn't covered by our backwards compatibility
guarantees. However, Variable is documented API.
> 1.) Currently `Variable("unresolvable")` and
> `FilterExpression("unresolvable", p)` resolve differently: Variable
> raises VariableDoesNotExist and FilterExpression returns
> TEMPLATE_STRING_IF_INVALID. Except when `ignore_failures=True` is
> given. But `FilterExpression("foo|cut:unresolvable", p)` will again
> raise VariableDoesNotExist - regardless of `ignore_failures=True`.
>
> My Expression implementation unifies these behaviours: If any part of
> an expression is unresolvable a LookupError will be raised.
> `ignore_failures` will be deprecated but there's a resolve_safe()
> method on the Expression base class that reads:
>
> def resolve_safe(self, context, default=None):
> try:
> return self.resolve(context)
> except LookupError:
> return default
>
> This would be a small backwards incompatible change. I have one
> failing test (exception02) because the ExtendsNode implementation
> depends on the current FilterExpression behaviour.
It's either backwards compatible or it isn't. Backwards compatibility
is a requirement, not an optional extra.
> 2.) Currently `Variable("a._hidden")` works - but
> `FilterExpression("a._hidden", p)` raises a TemplateSyntaxError. This
> would be unified: lookup parts may not start with an underscore. If
> it's not acceptable to break bc here leading underscores might simply
> be allowed.
I'm inclined to say this is a bug with FilterExpression. Underscored
variables shouldn't ever be exposed.
> 3.) Numeric literals ending with "." are currently treated as
> Variables. The following test (ifequal-numeric07) succeds because
> `ignore_failures=True` in IfEqualNode suppresses the inevitable
> VariableDoesNotExist exception and then compares None to 2: ('{%
> ifequal x 2. %}yes{% endifequal %}', {'x': 2}, ''). My current
> implementation raises a TemplateSyntaxError as soon as it encounters a
> numeric literal with a trailing dot. This could easily be made
> backwards compatible if it's considered worth it.
Sorry, but this one can't change. "2." is a tested format for handling
floats; the fact that this is inconvenient to your parser is
irrelevant.
> Tags
> =
> * {% url ... %}, {% ssi ... %} currently accept unquoted literal
> strings. This will continue to work but the preferred syntax will use
> properly quoted strings. This may one day allow for viewnames and ssi
> paths that come from expressions.
At this point, this sort of fix can't happen until v2.0. It's would be
a major change at this point. It's nice to know that the template
parsing tools will handle it when the time comes, but I would expect
that to be true of _any_ rework of the parser.
> * {% if not %} would fail with my current implementation. This is
> fixable. But I'm not sure it's worth it: not/and/or should be keywords
> in the context of boolean expressions.
I'm unclear what you're proposing here. {% if not %} is a well
documented API, so i
Re: django.template refactoring (again) #7806
On Tue, Sep 29, 2009 at 12:44 AM, Johannes Dollinger
wrote:
>
>>> Variable and FilterExpression will be deprecated as they require the
>>> caller to know the length of the expression in advance.
>>
>> I'm not sure I follow this assertion. I have no problem believing
>> FilterExpression can be made cleaner, but Variable takes an expression
>> like 'article.section', plus a context, and resolves it into a string.
>> In itself, it seems like a well built and stable piece of API.
>
> To get this expression string in the first place you have to split
> Token.contents somehow. smart_split() does that well for space
> delimited expressions.
> But if you try to parse something like {% url %} you have to split its
> results again: "foo.bar,baz|filter:arg,42" won't do it. The current {%
> url %} parser now resorts to `str.split(",")` and
> {% url viewname list|join:"," %}
> will break it. Of course that's a corner case and could be fixed with
> something like `smart_split(delim=",")`. But it would be much more
> elegant if you could just read an expression from a stream of tokens.
> That's what I meant when I said "the {% url %} parser is broken by
> design". I didn't mean to sound harsh - {% url %}'s parser is a
> reasonable tradeoff between simplicity and correctness.
Sure - that explains why FilterExpression is a problem, but I don't
see why Variable is affected. Once you've parsed your expression into
tokens, those tokens that are known to be variables need to convert
'foo.bar' into something derived from context.
>>> 1.) Currently `Variable("unresolvable")` and
>>> `FilterExpression("unresolvable", p)` resolve differently: Variable
>>> raises VariableDoesNotExist and FilterExpression returns
>>> TEMPLATE_STRING_IF_INVALID. Except when `ignore_failures=True` is
>>> given. But `FilterExpression("foo|cut:unresolvable", p)` will again
>>> raise VariableDoesNotExist - regardless of `ignore_failures=True`.
>>>
>>> My Expression implementation unifies these behaviours: If any part of
>>> an expression is unresolvable a LookupError will be raised.
>>> `ignore_failures` will be deprecated but there's a resolve_safe()
>>> method on the Expression base class that reads:
>>>
>>> def resolve_safe(self, context, default=None):
>>> try:
>>> return self.resolve(context)
>>> except LookupError:
>>> return default
>>>
>>> This would be a small backwards incompatible change. I have one
>>> failing test (exception02) because the ExtendsNode implementation
>>> depends on the current FilterExpression behaviour.
>>
>> It's either backwards compatible or it isn't. Backwards compatibility
>> is a requirement, not an optional extra.
>
> If FilterExpression is not part of the public API this is a non-issue.
> The problem was that unresolvable variables were treated differently
> from unresolvable filter arguments.
While FilterExpression isn't part of the public API, the effects of
using FilterExpression _are_ part of public API. If I have code that
currently fails silently because of a badly named variable, *that
behaviour cannot change*. The fact that FilterExpression raises (or
doesn't raise) an exception is irrelevant. How that expression is
surfaced to the end-user is _very_ relevant.
>> I don't want to sound dismissive of the work you're done here, but
>> your comments in this post haven't inspired me to go looking deeper.
>> You've been a little cavalier with the term "backwards incompatible"
>> on a couple of occasions, which is something that simply isn't
>> acceptable in something as prominent and well documented as Django's
>> template language.
>
> Criticism is welcome. If FilterExpression is not public API ,
> everything should be backwards compatible now. That was the goal from
> the beginning.
> The {% if not %} and Variable("2.") fixes are ugly but compact.
> All tests pass (with two minor corrections: {% foo | bar %} is now
> valid and FilterExpression internals have changed).
The changes to internals don't especially concern me. However, I'm
unconvinced that "foo | bar" is a desirable change. I can see how it
would make your life easier, but unfortunately, that isn't the
criteria here :-)
>> There are bugs in the template system. Many of these are caused by
>> inconsistent handling of parsing, especially of variables. If you can
>> point at something that you think is a bug (such as the handlng of
>> foo._attrib), then it's no longer covered by backwards compatibility.
>> However, you don't get that accommodation simply because something
>> doesn't fit into your nice new parsing scheme.
>>
>> Now, some of this might just be a misunderstanding on my part -
>> especially with regards to what is partially implemented, what you
>> intend to fix, and what you think can't (or shouldn't) be fixed.
>> You've spent a lot of time describing your new parsing API, but not a
>> lot of time describing why the new API is required. To that end, I'm
>> not entirely sure how much
Re: Model.objects.raw() (#11863)
On Tue, Sep 29, 2009 at 9:29 AM, Alex Gaynor wrote: > > On Mon, Sep 28, 2009 at 9:24 PM, SeanOC wrote: >> >> Hello All, >> >> During the Djangocon sprints I started to work on a patch which would >> add a nicer interface for dealing with raw SQL queries. While there I >> talked to RKM about where it should fit into the ORM API and where in >> the code base should live. I've finally gotten around to finishing >> the code I wrote during the sprint and have posted a patch to the >> related ticket (http://code.djangoproject.com/ticket/11863). You can >> also get the code from http://github.com/SeanOC/django. >> >> So far the patch is functional and has some basic unit tests but it is >> not documented. I'll be working on the documentation this week. In >> the mean time, the unit tests are probably the best place too look for >> how to use the code. >> >> If anybody would like to look over the code and provide some feedback >> it would be greatly appreciated. >> >> Thanks! >> >> -SeanOC >> > >> > > So my question, and this is something I've been thinking about a lot > of the proposals lately is: why should this be in Django itself. This > looks to me like something that would work perfectly well outside of > Django itself, indeed it's just a custom manager. Yes, this *could* be done entirely externally. However, I think it is a manifestation of a pattern that we actively encourage, so therefore we should provide nice API support for it. I've lost count of the number of times I've said "ORM != SQL, so just use a cursor and write raw SQL". However, "write raw SQL" isn't always trivial, since you don't get back ORM objects. If you want ORM objects, you have to: (1) know about the trick of instantiating an object with the unrolled list version of a cursor, and (2) ensure that you've got all your columns specified in the right order. We can fix (1) with some documentation, but (2) is one of those nasty implementation details that you don't know you've got right until everything blows up in your face. There's also an edge case where two versions of a table might end up with different column orders due to applying different migration strategies on each version. If this happens, then the cursor approach fails because there is no consistent column order. If we can provide API-level support to make it easier to write custom SQL, I think we should do so. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: admin - form instantiation add_view, change_view
On Tue, Sep 29, 2009 at 3:51 PM, Peter Cicman wrote: > > Wouldn't it be handy to add get_form_instance function to ModelAdmin? > Currently there is function get_form, which actually returns > FormClass. This is then getting instantiated on several places. > Sometimes its important to have possibility to add some attribute to a > form / override some field choices, etc... > > There are two ways how to do it now: > 1.) copy / override both add_view, change_view - too much code > inside, not very handy, i think they should be split anyway. > 2.) FakeForm class instanciated on __call__ (hacky).. You've missed the third option: define your own form class. If you create your own ModelForm subclass based on the model you want to display in the admin, you can override or set whatever attributes you want, and then tell the ModelAdmin to use your custom form. No runtime modification of the form instance is required. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Model.objects.raw() (#11863)
On Tue, Sep 29, 2009 at 4:27 PM, David Reynolds
wrote:
>
> Russ,
>
> On 29 Sep 2009, at 03:25, Russell Keith-Magee wrote:
>
>> (1) know about the trick of instantiating an object with the
>> unrolled list version of a cursor, and
>
>
> Any chance you could expand upon this?
Sure. Assume a simple model:
class Author(Model):
name = CharField()
age = IntegerField()
Now, in your code, get a cursor and issue a SQL statement:
from django.db import connection.
cursor = connection.cursor()
cursor.execte('SELECT id, name, age FROM myapp_author')
result = cursor.fetchone()
At this point, result holds a tuple containing (id, name, age). You
can instantiate an instance of Author by unrolling this tuple:
instance = Author(*result)
if you want multiple instances, use cursor.fetchall():
results = cursor.fetchall()
instances = [Author(*result) for result in results]
You need to be a little careful with the fetchall version because you
could end up with a _lot_ of results - but that's really just the
standard cursor usage warning.
The real caveat: the order of the columns you SELECT *must* match the
order in which the fields are specified in the model. For example, if
you made the following SQL query:
cursor.execute('SELECT id, age, name FROM myapp_author')
the query will work fine, but you'll get a TypeError when you create
the object because 'age' can't be coerced into a string. If the two
fields that are out of order are the same data type, you won't get any
errors at all - you'll just get a badly represented instance. Hilarity
ensues.
This trick is exactly what Django does internally when it constructs
object instances. However, in the Django internals, it is a completely
automated process - Django issues the query and parses the results, so
there's no risk of getting the column order wrong.
There are some ways to work around the column ordering problem. For
example, you can interrogate the cursor to get the name of the columns
that have been returned. This is what Sean has done in his patch to
make the raw() call a little more robust. This code is completely
generic; hence the interest in adding this to core.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal for 1.2: built-in logging with django.core.log
On Tue, Sep 29, 2009 at 5:09 PM, Vinay Sajip wrote: > > On Sep 17, 3:04 pm, Russell Keith-Magee > wrote: >> In the absence of specifics, this makes me a little bit nervous. The >> Python logging interface may be very Java-heavy and complex, but it is >> a thoroughly known quantity, and it houses a lot of features. > > See my comment about Java-heavy being FUD in Simon's initial post. First off - let me reinforce that I'm in your camp here - I like Python's logger, and I think we should be adding logging to Django. Any hesitation I have expressed is mostly a function of institutional inertia, especially with regards to Adrian's historical position on logging. However, I would point out that IMHO, FUD is an accurate description of the state of play - though probably not in the way you probably meant. Python's logging api _looks_ a lot like log4j in parts. This is at least partially because there's a limit to how many ways you can express 'log.debug()' before you start to copy. However, as a result, there's a lot of Fear, Uncertainty and Doubt as to whether a framework that apparently has Java heritage is going to be any good in Python. Don't forget that a lot of us (myself included) got into writing Python to get away from the stupidities of the Java world. Those scars are deep, and aren't going away in a hurry. Speaking personally, log4j is responsible for a lot of those scars, due in no small part to the abysmal documentation for that project. >> I'm also not entirely convinced that the answer here isn't just >> documentation. The documentation for log4j has historically been >> pretty awful, and while Python's documentation is an improvement, it >> could certainly be better IMHO. Good documentation for how to use >> logging in the context of Django could go a long way. >> > > I'm working with Doug Hellmann (PyMOTW) to try and improve the layout > of the logging documentation in Python. I'm not asking for patches > (though it would be nice), but if you can give *specific* criticisms > (e.g. what you think is missing, or unclear) then that will focus our > efforts. My comment was actually directed at Django's documentation, which is currently silent on the issue of logging - and probably shouldn't be. However, since you're interested in feedback, my suggestion would be to look at every defense you've made of logging in this thread (and any other threads where you've had similar arguments), and work out why the current docs have allowed those viewpoints to be established as apparent fact. Some examples: * Acknowledge that there is some Java heritage, but point out that this doesn't mean it's a bad thing, and that there is a lot that _isn't_ Java based about Python's logger. * Highlight the important architectural picture. As you noted in another reply - the logger and the handler are quite separate, and this gives a lot of power. However, the existence and significance of that architectural separation isn't really a major feature of the current docs. At present, the architectural bits are buried inside API discussion, but understanding this architecture is important if you're going to understand why logging works the way it does, and understand that logging isn't just putting lines into a file. * Make the simple example actually simple. IMHO, a single-file simple logging example is good for exactly 2 things: - showing how to configure the simplest possible case of logging - explaining the "why don't I have any output" problem. Tasks like configuring the logger to use a rotating file handler are important, but can wait for much later - once issues of basic usage and architecture have been established. * Better examples of how logging works in the real world. All the examples focus on single file projects. Most of the complexities I've had with logging stem from how to use it in a multiple-file project, yet as far as I can make out, there is very little discussion of how logging should be used in a real multiple-file project. - Should I have one logger instance per module? One per conceptual "task"? - You've used "logging.getLogger(__name__)" in this thread, but this pattern isn't mentioned once in the docs. Is this best practice, or a quick-and-dirty hack? - When I have multiple loggers across multiple files, how do I configure logging? Should I be putting logging.config.fileConfig() at the start of every python file, or should I put the logging config into a single python file somewhere that configures logging, and import that module as needed? >> Details notwithstanding, I'm +1 to the idea of adding logging to the >> core framework - or, at least, making it easier to use logs for &
Re: Proposal for 1.2: built-in logging with django.core.log
On Tue, Sep 29, 2009 at 9:00 PM, Waylan Limberg wrote:
>
> On Tue, Sep 29, 2009 at 4:36 AM, Vinay Sajip wrote:
>>
>>
>>
>> On Sep 17, 9:25 am, Simon Willison wrote:
>>> Problems and challenges
>>> ===
>>>
>>> 1. The Python logging module isn't very nicely designed - its Java
>>> heritage shines through, and things like logging.basicConfig behave in
>>> unintuitive ways (if you call basicConfig twice the second call fails
>>> silently but has no effect). This is why I suggest wrapping it in our
>>> own higher level interface.
>>
>> Simon, I'm the author of Python's logging package. Sorry for the delay
>> in replying, I've been away from this list awhile. I think the "Java
>> heritage shines through" is just FUD. basicConfig's behaviour is fully
>> documented here:
>>
>> http://docs.python.org/library/logging.html#logging.basicConfig
>>
>> Including the fact that it sometimes (by design) has no effect.
>>
>> There are a lot of people for whom logging just means writing to a
>> file, and that's why they have difficulty understanding why logging is
>> designed as it is. I would suggest you take a quick look at
>>
>> http://plumberjack.blogspot.com/2009/09/python-logging-101.html
>>
>> and then tell me why you think Python logging isn't well designed for
>> its purpose. You can do basic logging with two lines of setup (one
>> line if you ignore the import):
>>
>> import logging
>> logging.basicConfig(level=logging.DEBUG,filename='/path/to/my/log',
>> format='%(asctime)s %(message)s')
>>
>> and then
>>
>> logging.getLogger(__name__).debug("Just checking this works")
>>
>> Not too sure where the Java heritage is there, or where the hard part
>> is.
>>
>
> The hard part is that basicConfig only works like that back to Python
> 2.4 yet Django supports 2.3. When I added logging to Python-Markdown,
> this was the hardest part. Figuring out how to configure logging so
> that it works in 2.3 as well. The documentation is not exactly helpful
> in that regard.
...
> Of course, it is possible that I'm missing something obvious.
As luck would have it, you are :-)
Django 1.2 will drop formal support for Python 2.3.
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Adding an option to re-test only failed tests
On Wed, Sep 30, 2009 at 3:47 AM, Simon Willison wrote: > > On Sep 29, 7:34 pm, Rob Madole wrote: >> TEST_RUNNER = 'django.contrib.test.nose.run_tests' >> >> There might be some futzy bits to make that actually work, but I think >> it'd doable. > > I'd love to see this working. Obviously this would work just as well > implemented as an external project - but if it's as useful as it > sounds I'd personally be up for including it in core, if only to > promote the usage of nose amongst Django developers (and hence help > weaken the impression that Django doesn't integrate well enough with > the wider Python community). I'm yet to be convinced that Nose should be the default test runner for the simple reason that it doesn't come out of the box with Python. However, I agree that using Nose with Django should be as painless as possible. I included the TEST_RUNNER setting specifically for this reason. I haven't seen any reports in Trac that the capabilities of TEST_RUNNER aren't suitable for the task, and I've seen several snippets and blog posts indicating that Nose can be used with Django. If I'm incorrect on this, please let me know (or better still, open a ticket in Trac). Then there is the issue of whether Django should be responsible for shipping a Nose-compatible test runner, or whether that is Nose's responsibility. Historically, I've been of the opinion that it should be Nose's responsibility to ship a test runner, but I'm open to other opinions on this. I'm slightly hesitant to start building extra features like --failfast into Django's testing tools, especially when tools like Nose already cover this territory. Django isn't a test framework tool, and I'm hesitant to support proposals that try to turn it into one. Russ %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal for 1.2: built-in logging with django.core.log
On Tue, Sep 29, 2009 at 10:59 PM, Vinay Sajip wrote: > > On Sep 29, 1:53 pm, Russell Keith-Magee > wrote: >> >> However, since you're interested in feedback, my suggestion would be >> to look at every defense you've made of logging in this thread (and >> any other threads where you've had similar arguments), and work out >> why the current docs have allowed those viewpoints to be established >> as apparent fact. Some examples: >> >> * Acknowledge that there is some Java heritage, but point out that >> this doesn't mean it's a bad thing, and that there is a lot that >> _isn't_ Java based about Python's logger. >> > > That's easier to do when people raise specific points, rather than > talk about Java heritage in an arm-waving way, as if it's an offshoot > of the Black Death ;-) I was thinking that a calming, motherly "there there, it's all right, the boogeymonster isn't real" would do the trick :-) >> * Highlight the important architectural picture. As you noted in >> another reply - the logger and the handler are quite separate, and >> this gives a lot of power. However, the existence and significance of >> that architectural separation isn't really a major feature of the >> current docs. At present, the architectural bits are buried inside API > > That's because the docs are really pitched mainly as a a reference > guide. I suppose this is a big part of the problem. The logging module isn't a trivial API, and you really need to understand how it works before you can use it effectively. What is needed is a really good tutorial; what we have is a reference guide with a little bit of a tutorial tacked on the front. The reference is needed, but the tutorial is much more important from the point of view of getting the message out and encouraging people to use the API. >> discussion, but understanding this architecture is important if you're >> going to understand why logging works the way it does, and understand >> that logging isn't just putting lines into a file. > > I've recently created a blog about Python logging, where I talk about > logging from first principles and try to show why the design of Python > logging is as it is. It's not perfect, but it's a start. > > http://plumberjack.blogspot.com/2009/09/python-logging-101.html I saw this, and yes, it's a good start. However, it (or a version of it) needs to be formalized and in the official docs, not lingering on a blog somewhere. >> * Make the simple example actually simple. IMHO, a single-file simple >> logging example is good for exactly 2 things: >> - showing how to configure the simplest possible case of logging >> - explaining the "why don't I have any output" problem. > > I'm not sure what you're getting at. Sometimes, those two things is > all that people want to know at that time. Agreed, it's important that the simple use case is demonstrated. However, in the docs, the simple example is then used as a staging ground for demonstrating rotating file loggers and other things that a simple example doesn't need. Logging is a complex topic. A simple example doesn't provide the complexity that is required to demonstrate the strengths of the API. The simple example is useful for demonstrating the "hello world" case, but not for demonstrating more complex features. On the subject of examples, another suggestion: I'm wary of examples that try to be too smart. Take the logging level demonstration (the 5th code snippet in 16.6.1.1). This code very cleverly writes a script that can take a command line argument and turn it into a logging level, but in being clever, it obscures the point of the example - that you can output log messages at any level, but the configuration determines which ones are output. When you're trying to demonstrate the simple stuff, the less extraneous detail, the better. The next example (which demonstrates multiple loggers) is much clearer - it's obvious from first inspection what the code is doing. >> > They (logging and signals) are two different things. Python logging >> > allows you to consider the dimensions "What happened?", "Where did it >> > happen?", "How important is it?" and "Who wants to know?" >> > intelligently, and in particular it treats "What happened" and "Who >> > wants to know?" orthogonally. You get a lot of ways of getting >> > information to *people* whereas signals is more about letting *code* >> > know what's going on. >> >> Granted, although the two aren't mutually exclusive. Af
Re: Model.objects.raw() (#11863)
On Fri, Oct 2, 2009 at 7:35 PM, mrts wrote: > > Wishful thinking follows. > > It would be awesome if one could mix ordinary QuerySet methods > with raw() (or, rather, raw_extra(), see below for that). While I can see what you're aiming at here, I'm not really a fan of the idea. Django's ORM is designed to make the simple cases really simple, but once you move beyond the basics, you really should be looking to use raw SQL. When you try to mash segments of raw SQL into Django's internal query representation, it's very easy to start breaking things. extra() is already really fragile when it comes to interacting with other query features. Increasing the complexity of the SQL segments that you can inject into a query isn't going to improve the situation. I'm in favor of raw() specifically because it is only trying to make the output of raw SQL statements a little more palatable. It's interesting to me specifically because it doesn't try to integrate with normal Django queries. It makes it easier to use raw SQL without increasing the complexity of the query engine. Rather than trying to work out how to cram a query into Django's ORM, we acknowledge that Django's ORM has strengths, but for complex cases, raw SQL is still the language of choice. I think there are some things that we might be able to do to make writing the raw SQL a little easier - for example, allowing string substitutions for common parts of the query: SELECT %(columns)s FROM %(db_table) ... but even these I could live without. The important part is to provide a better answer for users that have a query that exceeds the capabilities of Django's ORM. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
