Re: The create/update/delete generic views need a 'message' parameter...
Point of clarification, it'd be a GET param, since you can't add POST in a redirect ;-) -- I do not fear computers. I fear the lack of them. -- Isaac Asimov --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Questions about model.save()
I've been looking at save() recently for work on http://code.djangoproject.com/ticket/4102 and I noticed what seems to be a problem in the primary key logic, but I'm not entirely sure :) In the block for saving an existing model object, it uses the non_pks list which is generated by testing for the primary_key flag on fields, however the block for inserting a new row tests if the field is an AutoField, not if it has primary_key set. Wouldn't this cause it to insert the primary key field regardless of if you'd specified it or not? As I think about it, a non-auto primary_key probably has to be specified in most situations, but it seems like it should still check :) I'm also curious for thoughts on an issue with the ticket I mentioned above; should the specified list of fields be used for inserting as well as updating? And if it should, should the pk be used if specified in the model regardless, or should you have to specify it in the field list? (or should I move this question to the ticket itself?) Thanks for any insights (or corrections) :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Questions about model.save()
On Apr 21, 9:53 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Your database may still have a serial value > on that field, for example, or there may be a trigger that does the > value computation. Both of these are a little unrealistic, but not out > of the bounds of possibility (because people do some pretty weird stuff > with databases and then complain when you take away their toys). In those instances though, wouldn't you want to leave the primary key field out of the insert? Or do non-specified fields get left out no matter what since there's no data there? > Validation is not the save() method's responsibility because it's not > always obvious what the right answer is. Took me a while to wrap my > brain around that when I starting working in that part of the code, but > it's an idea that works quite well when we apply it consistently. I'm probably missing something simple, but I don't see how validation ties into this - I'm not suggesting it needs to make sure there are valid values set in anything, it just seems that it's using the wrong metric to determine if a field is a primary key or not :) > There's going to be some interesting validation issues in that case. > You'll be able to save a model with only some of the fields set > correctly. I'm not sure that's a good idea. It's also a mark against the > whole concept, in some respects. Wouldn't it be fine though if the fields you leave out have valid defaults in the database? You'd have to be careful not to leave out a field you really want to save, but that's not much different than remembering to set a field in the first place :) > It's not universally true that not updating the same fields won't lead > to problems, because the two functions could have overlapping WHERE > clause constraints (or the WHERE clause of one could overlap the updated > columns of the other). So that part of the justification doesn't support > the inclusion of the patch. None of the databases we support widely have > column-level locking, as far as I'm aware (it wouldn't make a lot of > sense under the covers). While not universal, I think there are enough cases where it does work to make it a valid consideration, even if it isn't a full justification on its own :) > What speed-ups are you seeing on what sort of > use-cases with this change? I haven't done any testing yet - the performance comment was based on things others have said to me on how SELECTs involving columns with a lot of data in them can be slower, so I figured that UPDATEs with large blocks of text could be similarly impaired - if that's incorrect, then scratch the performance idea :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Questions about model.save()
On Apr 22, 2:42 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Yes, it would work. Why is it necessary to introduce the complexity (and > risk of screwing it up), though? We have the default attribute on models > for this type of thing. You're really leaking abstractions here. I'm not saying we need to have it on INSERTs, I mainly want it for UPDATE :) > Conceptually, Django works with Python models that just happen to be > stored (sometimes) in an SQL database. You are trying to bring the SQL > database more into the foreground here (which is admittedly something > that happens elsewhere too -- not ideal in any of those cases). I'm not > sure that you're solving a problem that needs solving here. Where else could it be solved though? The only other solution I can see is locking the entire row to prevent conflicts, but that can definitely slow things down :) > As an aside, the information about SELECT statements is not really > accurate. In a moderately complex query, filtering the data is a much > larger component of the time budget than reading the results from disk, > regardless of the columns retrieved. One reason for this is that the > database doesn't just read the columns you want from disk. It has to > read in multiples of some contiguous block size (typically 8K or more), > so it will read a large portion of the contents of each row whenever you > access any random selection of data in the row -- ergo reading the data > for a table is relatively constant and working out which rows to > actually read is more important (disk access is slwww). You *can* > blow this rule out of the water by using horribly complex computed > columns or trivial constraints, but the first case is rare, particularly > in Django scenarios, and the second case is so fast anyway that the > proportion of the time budget spent on each part is effectively > irrelevant. > > I don't have any similar information for updates, although I suspect > there's going to be similar conditions at play. Particularly because the > Django usage patterns will involve updating only a single row in each > table at a time -- so there aren't any complex constraints used to > filter the rows -- which again falls into the situation where the total > elapsed time is so small as not be worth micro-optimising. Timing the > performance will be necessary. Ok, I stand corrected on that aspect of performance :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Drag and Drop Ordering in the Admin Overview
> If we implement it ourselves should we do this against the new-forms > admin branch or the trunk? It'd probably be better to target it to newforms-admin since the current admin will be going away once that is ready, so you wouldn't have to update it later. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Probable bug in templates - default tags not always loading properly
User reported an issue, http://code.djangoproject.com/ticket/7377 Alex keeps closing it, but this appears to be a valid bug, which I can duplicate every time I open a python shell: http://dpaste.com/55054/ As posted in the ticket, it appears that the default tags are not loaded until the file loader.py is parsed - so if you import Template and Context, they don't work, yet the moment you import loader, they do - is this an intentional decision, or a valid issue? -- Collin Grady ...[Linux's] capacity to talk via any medium except smoke signals. -- Dr. Greg Wettstein, Roger Maris Cancer Center --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Probable bug in templates - default tags not always loading properly
Trevor Caira said the following: > Are you sure you're importing both Template and Context? I get the > same error as OP. I don't have to import Context to trip this, only Template -- Collin Grady Since a politician never believes what he says, he is surprised when others believe him. -- Charles DeGaulle --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Probable bug in templates - default tags not always loading properly
[EMAIL PROTECTED] said the following: > Yep, I just did it, how are you guys starting the python interpreter? python no manage.py, no ipython, nothing special, except my env has DJANGO_SETTINGS_MODULE set right -- Collin Grady I had the rare misfortune of being one of the first people to try and implement a PL/1 compiler. -- T. Cheatham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Response to "Shortcutting render_to_response"
Nathaniel Whiteinge said the following: > Either way, this is a bike-shed issue. In fact, he can simply do this: from django.views.generic.simple import direct_to_template as render_response and get the name he wants without patching anything :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Is there a django meta model ?
Jean-Christophe Kermagoret said the following: > I need this meta model to generate automatically django code from models. > > If there is no meta model, is there presently some code which would > permit to have code automatically generated from xml (or properly > properties) configuration files ? Usage questions like this belong on the django-users list :) This list is for the development of django itself. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Request for review
Not sure exactly how to phrase this, but James told me to bring these tickets up here to get some feedback on them - such as what exactly needs done to bring them to 'ready for checkin' as myself and others would like to get them in :) I did the basics of making sure the patches were updated, but feedback would be appreciated. Minor, quick performance enhancements: http://code.djangoproject.com/ticket/3460 http://code.djangoproject.com/ticket/3461 http://code.djangoproject.com/ticket/3575 Slightly larger, but also a good enhancement: http://code.djangoproject.com/ticket/4102 The first three are the big ones I'd like to help finish, but 4102 would also be very nice :) -- Collin Grady "We came. We saw. We kicked its ass." -- Bill Murray, _Ghostbusters_ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.db.connection request - add a key
hiwd said the following: > 'index': self.db.queries.__len__() Shouldn't that be len(self.db.queries) ? :) -- Collin Grady We are not anticipating any emergencies. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Latest Comments
Usage questions belong on the django-users list, not here - this list is for discussion of the development of django itself :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Bug in mod_python
Peter Melvyn said the following: > I see - is there a way how to pass such URL via Google interface? http://tinyurl.com ? :) -- Collin Grady If at first you don't succeed, you're doing about average. -- Leonard Levinson --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: List of DDN Tickets
Can I recommend http://code.djangoproject.com/ticket/4102 for the list? :) -- Collin Grady Bumper sticker: All the parts falling off this car are of the very finest British manufacture. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: List of DDN Tickets
AmanKow said the following: > Actually, 'required' is an argument to the *Model* field constructor, > and models are *not* always initialized from html forms. The field > certainly doesn't have to be represented as a checkbox in a form, > either. This is incorrect. Model fields have null and blank arguments, form fields have required. -- Collin Grady A chicken is an egg's way of producing more eggs. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: more DDN Tickets
Jeff Anderson said the following: > #4118 Do you have the wrong # here? That ticket is closed: duplicate :) -- Collin Grady It was a brave man that ate the first oyster. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RegexURLResolver.resolver can fall through and return None
Andreas Klöckner said the following: > Well, then the web site should hint at this fact, too. I was fairly close to > just abandoning the effort of trying to tell you about the issue I > encountered. It does. Quite clearly at the top of the 'new ticket' page, there are several notes about filing tickets, including this one: # If you're getting rejected by the spam filter, we apologize! The best way to avoid that is to register for an account and make sure you're logged in. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Spam detection
Mike Scott said the following: > Maybe the page after the block submission needs to be changed. And > maybe you could output a copy of the submitted text too just incase > you didn't have a copy written elsewhere. Something wrong with your browser's back button? :) -- Collin Grady Stay together, drag each other down. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: More secure user password reset
[EMAIL PROTECTED] said the following: > It sounds like what you are advocating is changing the password reset > to work similar to the way activation works in James Bennett's django- > registration, is that correct? Similar to that is what it sounds like - I'm definitely +1 on this - a lot of sites do it like this where you must confirm a password change to prevent this kind of thing - they could initiate as many requests as they wanted without actually changing anything. I'd suggest making the code to change the password a one-use-only item though, so that even if someone did sniff the code, it'd be useless after that. -- Collin Grady Abstainer, n.: A weak person who yields to the temptation of denying himself a pleasure. -- Ambrose Bierce, "The Devil's Dictionary" --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MySQL exact/iexact lookups change
George Vilches said the following: > As of http://code.djangoproject.com/changeset/7798 in the MySQL > DatabaseWrapper.operations, Malcolm has changed the "__exact" filter > to use '= BINARY' to force case-sensitive comparisons, which is > appropriate. > > I therefore propose that operations."__iexact" should be changed from > 'LIKE %s' to '= %s', which performs much better, and gives the same > results for the cases which the documentation specifically describes: > "Case-insensitive exact match". There's no reason to be using LIKE > here when the database gives us a better built-in option for the same > behavior. Actually, based on what I remember of my testing for #3575[1], = and LIKE were about the same when using a case insensitive collation (though I don't seem to have mentioned that in the ticket, since it didn't really matter there) [1] http://code.djangoproject.com/ticket/3575 -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django newforms RadioSelect issue
Questions of this nature should go on django-users, not django-developers - this list is for the development of Django itself, not usage questions :) -- Collin Grady Sentimentality -- that's what we call the sentiment we don't share. -- Graham Greene --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ManyToManyField in Admin list_display
Please send usage questions to django-users - this list is for the development of django itself. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
newforms-admin and urls (reverse/etc)
I know it's kind of late to bring this up, but I haven't been using the branch, so it hasn't been at the front of my mind at all :) newforms-admin currently uses a url match of ^admin/(.*) which sort of kills reversing - you can't just pass the parts in, you have to manually build the string for the rest of the URL. Would it be feasible to change that back to separate url matches like the current admin, or would that take too long at this close date? Or perhaps another method would be to give newforms-admin its own helper to generate URLs? It's nice to be able to link back to admin for staff members, so you can quickly go and edit a page, so I think any fix along these lines would be very useful :) -- Collin Grady "I only touch base with reality on an as-needed basis!" -- Royal Floyd Mengot (Klaus) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: bug in forms
On Tue, Sep 16, 2008 at 4:27 PM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > if name in self.cleaned_data and f.unique and not is_null_pk: > and in the doc, the variable self.cleaned is now self.clean_data You are incorrect. The variable was clean_data in 0.96 but changed to cleaned_data shortly after to avoid conflicts with validation functions for a field named "data" - you are reading old examples and/or docs. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: bug in forms
On Tue, Sep 16, 2008 at 4:33 PM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > i found this: > Changed in Django 1.0: The cleaned_data attribute was called > clean_data in earlier releases. > > in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index > > I make a mistake? That line also says what I said - it *used to be* clean_data in 0.96, but it *is* cleaned_data now. So if the line of code had clean_data, it would be wrong, but it has cleaned_data, so it is right. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: bug in forms
On Tue, Sep 16, 2008 at 4:40 PM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > sorry, you have reason, my english is bad and i am tired, but i have this > error: >>>> form.clean() > Traceback (most recent call last): > File "", line 1, in ? > File "/home/felipecastel/django1.0_src/django/forms/models.py", line > 208, in clean >self.validate_unique() > File "/home/felipecastel/django1.0_src/django/forms/models.py", line > 236, in validate_unique >if name in self.cleaned_data and f.unique and not is_null_pk: > AttributeError: 'IdeaForm' object has no attribute 'cleaned_data' >>>> > and i read the doc over and over again and i cant use the forms. This sounds like more of a usage question then (for instance I see you calling form.clean() manually for some reason), so you should take it to django-users :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Raise an Exception to return a Response
Wouldn't it be easier to use process_exception instead of process_view ? -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 'unicode' object has no attribute 'user'
On Thu, Sep 18, 2008 at 4:31 AM, laspal <[EMAIL PROTECTED]> wrote: > I am trying to send mail using sendmail. Getting the error 'unicode' > object has no attribute 'user' This question belongs on django-users, not django-development - this list is for the development of django itself, not usage questions or errors like this :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
This is related to http://code.djangoproject.com/ticket/3460 -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: "things are ready" signal?
On Wed, Oct 1, 2008 at 2:04 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > So, would a signal there be useful? (no ticket filled yet) And, where > can one hook code for that? :) I don't think any such place exists, so there's nothing you can do for it. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: remove auth context processor dependancy for Admin
On Sat, Nov 1, 2008 at 9:45 AM, bo <[EMAIL PROTECTED]> wrote: > One aid in this area would be to remove the dependancy of > context_processor.auth in the Admin world (which most certainly needs > the user, messages and perms in the context) You can already do this - simply make your own subclass of AdminSite and override check_dependencies -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: remove auth context processor dependancy for Admin
On Sun, Nov 2, 2008 at 8:57 AM, bo <[EMAIL PROTECTED]> wrote: > Yes, that may be true. > > But why does the 'default' behavior impose these dependencies when > they are not required? As that context processor has this other 'side > effect' of making an entire site "Vary" under a cookie, hit the > session and hit the DB. I think you're confused - the context processor doesn't set a cookie, so it isn't causing any Vary behavior, and admin *does* currently depend on it - it needs the info the processor provides. Unless admin was rewritten to add them to context manually on every view, it will continue to need it. > and one would need to override every other function that calls > "template.RequestContext' which is most of the meat of sites.py. Uh, no you wouldn't - if you tell admin not to check for that context processor, you could replace the auth processor with a custom one that only works in admin's path and as such wouldn't add any db hits to the rest of the site. So if your goal is to make only admin do the queries for that data, it's entirely possible. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Model inheritance question
Usage questions belong on django-users, not django-developers - this list is for the discussion of the development of django itself. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: problem with inlineformset_factory
Usage questions belong on the django-users list - this list is for the development of django itself :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: login_required
On Mon, Nov 10, 2008 at 11:49 AM, Sebastian Bauer <[EMAIL PROTECTED]> wrote: > Hello, i think login_required should check that user is not only > authenticated, but also if is active. What do you think about this change? I think you can write your own decorator to do that, and it would be a backwards-incompatible change, so it isn't likely to happen :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Suggestion for doc search
Would it be possible to have the doc search add a "-inurl:olddocs" to all search queries? Anytime you search for something without it right now, you always hit the redirect warning, even though there was no redirect, and it was confusing a few users today in IRC, since they thought they hit an out of date doc page. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
On Tue, Nov 18, 2008 at 4:43 PM, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > And that's very doable, and I'm with you on this. I hate having to > pass context_instance. Long lines. Although nothing stops someone from writing their own wrapper if they don't like direct_to_template for some reason :) http://www.djangosnippets.org/snippets/3/ -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Additional Fields in Core
Make app. Post on Google Code (or other site) Profit! :) These shouldn't need to be in core to be used. -- Collin Grady --~--~-~--~~~---~--~~ 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: test failures when CACHE_BACKEND is 'dummy:///'
On Wed, Dec 17, 2008 at 8:45 PM, Tai Lee wrote: > Is this a bug? If not strictly a bug, would it be worth changing this > behaviour to allow developers to more easily run tests on their > applications as they develop? I told you in channel that it's normal - dummy does not cache anything - the tests rely on caching, since they test the cache session backend. There is no way to make them not fail unless you either do not test that, or make the dummy cache backend /not/ a dummy cache backend anymore. -- Collin Grady --~--~-~--~~~---~--~~ 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: view permission for contrib.admin
On Thu, Dec 18, 2008 at 8:30 AM, gert wrote: > Which was definitely what was intended on day one when the CHANGE, > ADD, DELETE permissions were created. Says you. Admin is for admins. Not limited users. Write your own views. -- Collin Grady --~--~-~--~~~---~--~~ 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: Problem with ORM
On Wed, Jan 14, 2009 at 9:51 AM, Sebastian Bauer wrote: > how orm can save second instance of the same row when its deleted? Deleting an object won't magically remove all references to it - the instance_2 variable still has a perfectly valid object, so saving it just reinserts a new copy of it. This is not a bug, as everything is working as intended :) -- Collin Grady --~--~-~--~~~---~--~~ 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: Problem with ORM
On Thu, Jan 15, 2009 at 2:09 PM, Jan Bednařík wrote: > That should not happen. > > instance.delete() > instance.save() > > should raise ObjectDoesNotExist exception. Any other behavior is bug. Why? You have a perfectly valid object instance, and you're then saving it. Just like if you had instantiated it. If you want it to fail if the object is gone, use force_update=True as you were told before. This is not an ORM bug, no matter how much you would like it to act otherwise. -- Collin Grady --~--~-~--~~~---~--~~ 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: #10244 FileFields can't be set to NULL in the db
It will only store NULL if you set it to None - if you leave the field
blank in a form or admin, there's still an empty string posted for
most string field types, so it stores that empty string.
On Fri, Feb 20, 2009 at 4:57 AM, oyvind.salt...@gmail.com
wrote:
>
> If a FileField with null=True is set to None, the db stores '' in the
> db and not NULL as I would expect.
>
> Also, if a FileField has both blank=True and null=True a ModelForm
> without a file will save '' in the db, not sure if this is the desired
> behaviour.
>
> So the question is should the behaviour be as-is and if not is the
> correct place to solve it in get_db_prep_value?
>
> Example of code that this issue affects:
>
> Model.objects.filter(filefield=u'') seems wrong as compared to
> Model.objects.filter(filefield__isnull=True)
>
> Model.objects.aggregate(Count('filefield')) i would expect this to
> count objects with a file and not those without a file.
>
> This may relate to other fields aswell, if a field has both blank=True
> and null=True should it not store NULL in the db?
> >
>
--
Collin Grady
--~--~-~--~~~---~--~~
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: Creating "lazy" foreign keys
Seems you could just use an IntegerField and do it yourself, instead of expecting django to adapt itself to your bad db design :) On Sat, Feb 21, 2009 at 5:16 PM, Adys wrote: > > I see what you mean. I agree to an extent - data needs to stay as > clean as possible. But this isn't the goal in every situation, and > doesn't always mean that data is erroneous - it can simply be lacking. > > Simplified use case: > I've got for example a table that contains foreignkeys to another > "additional_names" table no longer maintained publicly. What I want to > do in this case is use the few hundred rows I gathered from the last > public versions, and leave the other ones blank. That way, in my app, > I can display "This object has an additional name, but I don't know > which". Having listings like that allows me to present data that would > need post-update manual work, should there ever be enough references > to a specific lacking row in additional_names to figure it out and > stub it properly. > > When nulling out the foreign keys is an option, I already do that, > it's not a problem. The problem hits when I have to keep the fkey IDs > intact. > > On Feb 22, 1:48 am, Killian wrote: >> Sorry for the previous one, accidentally pressed alt-s >> >> What I meant to say was: as far as I can see your problem is mostly covered >> by faulty db-design or maintenance, which is not something django should >> cover in my opinion, it seems logically you do a cleaning of your database >> to set all non-existing foreignkeys to NULL. >> >> 2009/2/22 Killian >> >> > Hi >> >> > 2009/2/21 Adys >> >> >> Hi there >> >> >> I've been thinking for the past couple of days of a simple "lazy" >> >> ForeignKey design (or whichever name would fit better). It's something >> >> I've tried really hard to find in Django, unsuccessfully. Some >> >> explanation first... >> >> > Lazy is imho not a decent name indeed, 'lazy' usually means relationships >> > aren't fetched prematurely (foreignkey object isn't fetched automatically), >> > which django does by default if I'm not mistaken. >> >> >> I tried to get some background on django-users, cf >> >>http://groups.google.com/group/django-users/browse_thread >> >> >> /thread/caec53feb0ddb43a# >> >> To make it short: My project reuses imported data. This data is *very* >> >> faulty and a lot of ForeignKeys point to deleted/non-existing rows. I >> >> can't afford checking integrity constantly (cf link). >> >> > As far I c >> >> >> A lazy ForeignKey would assume the data is valid, and return >> >> "something else" if it's not. I'm not sure what the best value >> >> returned would be. It could be a row with placeholder/default values, >> >> it could be an exception, etc. I haven't worked deeply with Django's >> >> codebase, I'm unsure about design details. >> >> The idea here is to be able to offer something "valid or unknown". I >> >> hope I'm not too unclear... >> >> > First of all, imho this isn't about "lazy", lazy usually means >> > relationships aren't fetched prematurely (foreignkey object isn't fetched >> > automatically), which django does by default. >> >> > Secondly, the NULL value in databases is actually defined originally as >> > Unknown, so it seams normal in your situation to default to None if your >> > relationship is undefined (and allow null=True in your model). >> >> >> I'm sure there's a better solution - I have yet to find it - but I >> >> would first like to hear feedback on a feature like that. If you feel >> >> it's a good idea I'm interested in working on it. If you feel >> >> otherwise, well... I'm still looking for a better suggestion. >> >> >> Cheers >> >> >> JL > > > -- Collin Grady --~--~-~--~~~---~--~~ 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: Creating "lazy" foreign keys
You completely misread the tone of the email - that *was* my pointer for how to do it - instead of trying to shoehorn it into ForeignKey where it doesn't belong, just use an IntegerField, possibly with model functions to do the querying (which could be made properties to act like fields) to get the info from the other table and return the default you want if the other row is missing. On Sun, Feb 22, 2009 at 2:51 AM, Adys wrote: > > Except... I'm not expecting anything. > > I'm going to work on this regardless, I'm just proposing to share my > work in exchange for a few pointers here and there. Sarcasm, and > blaming the user, is a very tasteless way of saying no. > > > On Feb 22, 10:52 am, Collin Grady wrote: >> Seems you could just use an IntegerField and do it yourself, instead >> of expecting django to adapt itself to your bad db design :) >> >> >> >> On Sat, Feb 21, 2009 at 5:16 PM, Adys wrote: >> >> > I see what you mean. I agree to an extent - data needs to stay as >> > clean as possible. But this isn't the goal in every situation, and >> > doesn't always mean that data is erroneous - it can simply be lacking. >> >> > Simplified use case: >> > I've got for example a table that contains foreignkeys to another >> > "additional_names" table no longer maintained publicly. What I want to >> > do in this case is use the few hundred rows I gathered from the last >> > public versions, and leave the other ones blank. That way, in my app, >> > I can display "This object has an additional name, but I don't know >> > which". Having listings like that allows me to present data that would >> > need post-update manual work, should there ever be enough references >> > to a specific lacking row in additional_names to figure it out and >> > stub it properly. >> >> > When nulling out the foreign keys is an option, I already do that, >> > it's not a problem. The problem hits when I have to keep the fkey IDs >> > intact. >> >> > On Feb 22, 1:48 am, Killian wrote: >> >> Sorry for the previous one, accidentally pressed alt-s >> >> >> What I meant to say was: as far as I can see your problem is mostly >> >> covered >> >> by faulty db-design or maintenance, which is not something django should >> >> cover in my opinion, it seems logically you do a cleaning of your database >> >> to set all non-existing foreignkeys to NULL. >> >> >> 2009/2/22 Killian >> >> >> > Hi >> >> >> > 2009/2/21 Adys >> >> >> >> Hi there >> >> >> >> I've been thinking for the past couple of days of a simple "lazy" >> >> >> ForeignKey design (or whichever name would fit better). It's something >> >> >> I've tried really hard to find in Django, unsuccessfully. Some >> >> >> explanation first... >> >> >> > Lazy is imho not a decent name indeed, 'lazy' usually means >> >> > relationships >> >> > aren't fetched prematurely (foreignkey object isn't fetched >> >> > automatically), >> >> > which django does by default if I'm not mistaken. >> >> >> >> I tried to get some background on django-users, cf >> >> >>http://groups.google.com/group/django-users/browse_thread >> >> >> >> /thread/caec53feb0ddb43a# >> >> >> To make it short: My project reuses imported data. This data is *very* >> >> >> faulty and a lot of ForeignKeys point to deleted/non-existing rows. I >> >> >> can't afford checking integrity constantly (cf link). >> >> >> > As far I c >> >> >> >> A lazy ForeignKey would assume the data is valid, and return >> >> >> "something else" if it's not. I'm not sure what the best value >> >> >> returned would be. It could be a row with placeholder/default values, >> >> >> it could be an exception, etc. I haven't worked deeply with Django's >> >> >> codebase, I'm unsure about design details. >> >> >> The idea here is to be able to offer something "valid or unknown". I >> >> >> hope I'm not too unclear... >> >> >> > First of all, imho this isn't about "lazy", lazy usually means >> >> > relationships aren't fetched
Re: Creating "lazy" foreign keys
Well he'd have to use an IntegerField, not a ForeignKey, but the same
idea applies - he can do his own validation/etc in the property
handlers.
On Mon, Feb 23, 2009 at 7:27 PM, Jerome Leclanche wrote:
>
> Sounds like that wouldn't work. Django fails on __init__ with invalid
> foreignkeys.
>
> On Tue, Feb 24, 2009 at 3:24 AM, join.toget...@gmail.com
> wrote:
>>
>> On Feb 22, 10:30 pm, Adys wrote:
>>> Not sure I follow you. You mean overriding the set property of a
>>> ForeignKey/IntegerField?
>>>
>>> On Feb 23, 6:23 am, "join.toget...@gmail.com"
>>>
>>> wrote:
>>> > What about something like a property()? The set method would act like
>>> > normal, but the get method would have some extra logic built into it
>>> > that would take care of everything.
>>
>> Something like the following:
>>
>> _other=models.ForeignKey('Other')
>>
>> def _set_other(self, o):
>> _other=o
>>
>> def _get_other(self):
>> try:
>> return _other
>> except Other.DoesNotExist:
>> return None
>>
>> other=property(_get_other,_set_other)
>>
>> When someone tries to access "other", it will call the _get_other()
>> method automagically, so you can have whatever logic you need in there
>> without forcing anything but the model to deal with it.
>> >
>>
>
>
>
> --
> Adys
>
> >
>
--
Collin Grady
--~--~-~--~~~---~--~~
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: My case for #9006
One could also set a default ordering on a model and have a consistent order everywhere :) -- Collin Grady --~--~-~--~~~---~--~~ 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: My case for #9006
Of course not - you can do .order_by() to clear ordering if you really don't want a default ordering somewhere, but all your examples sound like you do :) On Sat, Feb 28, 2009 at 3:02 PM, PauloS wrote: > > On Feb 27, 5:28 pm, Collin Grady wrote: >> One could also set a default ordering on a model and have a consistent >> order everywhere :) > > This way you have to pay the ORDER BY price for every query? > > > -- Collin Grady --~--~-~--~~~---~--~~ 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: Cache related values without needing to hit database twice
I think you should look at select_related() to solve most of those cases. -- Collin Grady --~--~-~--~~~---~--~~ 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: Creating objects with references together
Usage questions like this belong on the django-users list - this list
is for the development of django itself.
On Mon, Mar 16, 2009 at 9:38 AM, Yaniv Haber wrote:
>
> hi,
>
> I need to create 2 objects, one containing a reference to the other,
> in one shot. I get an IntegrityError exception while trying to do so,
> claiming that the foreign key is None on creation. Hope someone can
> help...
> (when I refresh the browser and rePOST the data it works as the
> Product object is already there and is not created at the same time)
>
> Thanks, Yaniv
>
> I have the following models:
>
> Class Product
> productId = models.AutoField(primary_key=True)
> name = models.CharField(max_length=200, unique=True)
> description = models.CharField(max_length=200, blank=True)
>
> Class Manufacturer
> manId = models.AutoField(primary_key=True)
> product = models.ForeignKey(Product)
> contact = models.ForeignKey(User)
> price = models.PositiveIntegerField()
>
> I created a form containing fields for both, with a 'save' function:
>
> class ProductForm(forms.Form):
> name = forms.CharField(max_length=200)
> description = forms.CharField(max_length=200)
> price = forms.IntegerField(min_value=0)
>
> def save(self):
> prod = Product(name=self.cleaned_data['name'],
> description=self.cleaned_data['description'])
> prod.save()
>
> ma = Manufacturer(product=prod,
> contact=self.data
> ['user'], # this is being passed by
> the view
> price=self.cleaned_data['price'])
> ma.save();
>
> The problem: the new product is being saved but on the
> manufacturer.save() I get the following exception:
>
> Exception Type: IntegrityError
> Exception Value: (1048, "Column 'product_id' cannot be null")
> Exception Location: C:\Development\Python25\Lib\site-packages\django
> \db\backends\mysql\base.py in execute, line 88
>
> Environment:
>
> Request Method: POST
> Request URL: http://localhost:8000/addproduct/
> Django Version: 1.0.2 final
> Python Version: 2.5.4
> Installed Applications:
> ['django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'django.contrib.admin',
> 'django.views.generic',
> 'mysite.myapp',
> 'registration']
> Installed Middleware:
> ('django.middleware.common.CommonMiddleware',
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> 'django.middleware.doc.XViewMiddleware')
>
>
> Traceback:
> File "C:\Development\Python25\Lib\site-packages\django\core\handlers
> \base.py" in get_response
> 86. response = callback(request, *callback_args,
> **callback_kwargs)
> File "C:\Development\Python25\Lib\site-packages\django\contrib\auth
> \decorators.py" in __call__
> 67. return self.view_func(request, *args, **kwargs)
> File "C:\Development\googleapp_projects\busa\..\mysite\myapp\views.py"
> in registerProduct
> 63. f.save()
> File "C:\Development\googleapp_projects\busa\..\mysite\myapp\forms.py"
> in save
> 76. ma.save();
> File "C:\Development\Python25\Lib\site-packages\django\db\models
> \base.py" in save
> 311. self.save_base(force_insert=force_insert,
> force_update=force_update)
>
>
> >
>
--
Collin Grady
--~--~-~--~~~---~--~~
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: Multiple admin forms
Usage questions belong on the django-users mailing list. This list is for the development of django itself. -- Collin Grady --~--~-~--~~~---~--~~ 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: #3182 -- model instance update() method and QuerySet update_or_create() method
On Mon, Mar 23, 2009 at 12:44 AM, Ivan Sagalaev wrote: > I'd like to chime in with another point of view. Not my own, I was just > in a discussion about it in our local forums and I don't want the idea > to vanish. > > A person there wanted an `update()` method too but not behaving like you > show. Instead he wanted it to update *just* the fields passed as > arguments. I.e. it should be equivalent to this: So more like http://code.djangoproject.com/ticket/4102 then ? :) -- Collin Grady --~--~-~--~~~---~--~~ 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: Use RequestContext if possible in default 500 error view
Perhaps the default 500 view could just include a few simple things like MEDIA_URL on its own? Alternatively, one can make a custom 500 handler with whatever info they want, instead of using django's default :) -- Collin Grady --~--~-~--~~~---~--~~ 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: Debugging unit test?
You probably want django-users, since this list is about the development of django itself, not other topics. On Sun, May 10, 2009 at 11:39 AM, Joshua Russo wrote: > > What do you use to debug the unit tests? I've been using Netbeans 6.5 > with the Python plugin but it's a bit buggy still and the unit tests > seem to have real issues with the debugger at the moment. > > > -- Collin Grady --~--~-~--~~~---~--~~ 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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
On Wed, May 13, 2009 at 2:36 AM, julianb wrote: > Since the ticket is one year old, that time had come and passed. The ticket's age is irrelevant. *right this minute*, everyone is focused on 1.1, so making a design decision for this ticket is not important right now. Once 1.1 is out, it can be revisited. Even if you got a decision right now, it would never have a chance of making it in to 1.1, so rushing the decision would be pointless anyway. -- Collin Grady --~--~-~--~~~---~--~~ 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: MEDIA_URL template tag/context processor/etc again
+1 on #1278 :) I think RequestContext is the better way of doing it - I think MEDIA_URL is every bit as common to use as the user info provided by the auth context processor, and that wasn't done with a tag either :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Allowing multiple {% block %}s in one template
This came up on IRC the other day and I had an idea on the subject -
I'm not sure if this would actually work well or not, but it can't
hurt to toss it out there :)
I was thinking of some format like so:
{% block foo,bar %}New content{% endblock %}
And having that now override both foo and bar. As for the handling of
block.super, I was thinking that {{ block.super }} would use the
proper parent content for the block it's replacing, so for instance
doing this:
{% block foo,bar %}{{ block.super }} - Some Site{% endblock %}
Would use foo's content when replacing foo, and bar's content when
replacing bar. In addition, if it's at all possible, I was thinking
something along the lines of {{ block.foo.super }} or
{{ block.super.foo }} could be used to grab one specific block's
content (less useful IMO, but I dunno)
Using this idea, the bug tracker title example would look pretty
straightforward:
# parent
{% block title %}Bug System - {% endblock %}
{% block header %}{% endblock %}
# child
{% block title,header %}{{ block.super }}{{ object.title }}{% endblock
%}
Which would then render as expected - title would have "Bug System - "
placed in front of the object's title, while header would not.
Ok, I think that about covers my idea, but I'm not really attached to
it if there are problems I'm not noticing :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: 4102, updating only specific fields / dirty flag
I was trying to bump the previous thread: http://groups.google.com/group/django-developers/browse_thread/thread/b8e2eaa6b5190b19/7e608ee8822d3a60 But Google Groups won't let me reply to it (maybe it's too old?) ;) The reason was the new patches, with the attempt at a 'dirty' flag so that it only has to update fields that changed. It occurs to me as I type this that a "force" option to save might go well with this to make it save everything regardless, but I'm still not sure if I'm missing any obvious gotchas in the current attempt :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 4102, updating only specific fields / dirty flag
On Jun 26, 5:12 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > One thing that jumps out from a quick read: there are no tests on the > patch. > > One test that springs to mind is to create two instances of the same > database row, change different fields and then save each one, re-query > the database and prove the two saves only updated their respective > columns. There might be some other cases that need testing two > (relations, for example?). I added a test along the lines of your suggestion, is it about what you had in mind? :) > My second thought is that overriding __setattr__ like that has some > drawbacks. It means that if any model in an application implements > __setattr__, they have to remember to call the Model version as well or > else nothing in core -- or any third-party app that was intended to work > in conjunction with other, unknown apps -- could ever assume the > parallel update condition holds in the future, if we wanted to use it. > It also slows things down on the fast path a bit (when this feature > isn't needed). The original version had the list of columns to save > being passed into Model.save(). That feels less intrusive. I'm not particularly tied to either method, so long as some form of this makes it in I'll be happy :) I also found (and fixed) an issue regarding __init__ differences between a model coming from the db and one you make yourself, but it requires an extra kwarg on __init__ - this may not be optimal so that may make things lean back towards the former method of adding an arg to save, but I'm not sure. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: urlconf, strings vs. callables
On Jul 10, 6:20 am, Carl Karsten <[EMAIL PROTECTED]> wrote:
> apply decorators? do tell...
>
> (sorry to turn this into a d-user post...)
>
> Ideally I would like to apply it to this whole tree:
>
> (r'^eventcal/', include('eventcal.urls')),
You can apply it to specific views, not to an include.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Translated fields
Have you seen http://code.google.com/p/i18ndynamic/ ? :) On Jul 11, 3:16 pm, Marc Garcia <[EMAIL PROTECTED]> wrote: > Hi all! > > I've been searching for a way to create a multilingual catalog with > django, and there is just one thing missing, a simple way for > translating information on database, for example having product > description in more than one language. > > I've checked translation module on django-utils, and django- > multilingual, and both solve the problem, but I want a more intuitive > way for end-users (who fill data in admin). > > I've designed an admin page with my > idea:http://vaig.be/2007/07/11/django-database-texts-translated/ > > I haven't seen any post or any ticket that anybody that is working on > something like that. If anybody does, please let me know. > > I'll start soon working on it, but I'm not an expert on hacking > django, is it posible to do that just in contrib? Unless it is, any > core developer think that it could be included in django code? I think > that outside english countries it's very necessary... > > Thanks, > Marc --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Unicode Keys
Passing raw GET params into a function seems like a recipe for disaster if you fail to validate something properly. Plus, unicode is allowed to be used as get/post keys, so not supporting it in the dict keys would cause problems. For instance, if I have an input with name="語" and request.POST doesn't support unicode, how do I then get the value for that? :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Move form_for_instance and form_for_model into django.db.models.Model?
This doesn't seem a far step from the model fields being able to return appropriate form fields, which they already do, so there's some tie-in already :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Adding support for ~ to Q objects (negation)
Simon requested I bring this up here - I was working through a problem with a user on IRC, and he noted that Q objects support the bitwise & and |, but not ~ - if you wanted to negate a Q object, you had to explicitly import QNot and use that instead. As such, the following patch was born, allowing ~q instead of QNot(q) :) http://code.djangoproject.com/ticket/4858 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Adding support for ~ to Q objects (negation)
Added a few tests and docs - not sure how good they are, but better than nothing :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Improvement suggestion for {% url %}
Couldn't you just use reverse() in your custom tag? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: contrib.auth.models.User and related_name on 'groups' attribute
group_obj.user_set.all() /is/ available :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Maybe we need more triagers? Or something else?
I like the idea of the voting app - there are several tickets I would +1 already ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feedback on alternate comments app
This post may be better suited for the django-users list. This list is for the discussion of the development of django itself, not apps that use django. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms suggestions - pre_clean? magic cleaned_data? - access to errors?
Malcolm Tredinnick said the following: > On Mon, 2007-08-13 at 18:18 -0700, sime wrote: >> 6. Maybe allow clean_method=x in field parameters, rather than have to >> create a custom field or repeat similar clean functions. > > You can do that one in this fashion... > > class MyForm(Form) >field1 = ... >field2 = ... > >def generic_clean(self): > # ... > >clean_field1 = generic_clean >clean_field2 = generic_clean > > The generic_clean method can even be outside the class (although it will > be called as a method function, so it needs to have the right > signature). Actually, this method won't work very well unless the clean_FOO methods are changed to take the value, since you'd have to know which field it's being called for. :) Unless that change does make it in, I don't see how you could do anything at all in there, unless you just wanted to return a static value :) -- Collin Grady I'm going to Boston to see my doctor. He's a very sick man. -- Fred Allen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: runserver --with-fixture
Brian Harring said the following: > 2) Adding functionality to automatically collect/serialize a stream of > interp. commands I think there might be some misunderstanding here - I believe he's saying to merely dump the fixture out again using the new database with changes - so if you start runserver off foo.json and edit the database, those edits will then be present in foo.json on exit, so you dont have to manually load/edit/dump. Not to do some sort of logging of python actions into a test somehow :) -- Collin Grady I use technology in order to hate it more properly. -- Nam June Paik --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: manage.py idea?
Rob Hudson said the following: > Would it be worthwhile to add a way to purge unused content types via > manage.py? It could look at INSTALLED_APPS and anything not installed > it removes? Wouldn't reset do that? ./manage.py reset auth contenttypes -- Collin Grady "Die? I should say not, dear fellow. No Barrymore would allow such a conventional thing to happen to him." -- John Barrymore's dying words --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: manage.py idea?
David Danier said the following: > Even if it did the id's might have changed and any generic relations be > broken. Shouldn't really be an issue with his scenario though, since he said this was during initial dev on the data model, so he wouldn't even have much (if any) data yet :) -- Collin Grady Perhaps no person can be a poet, or even enjoy poetry without a certain unsoundness of mind. -- Thomas Macaulay --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms suggestions - pre_clean? magic cleaned_data? - access to errors?
SmileyChris said the following: > The solution is that clean_* methods should just be passed the field's > value as an argument. > Even being backwards incompatible, I think it needs to be done. +1, passing them the value makes much more sense, IMO. -- Collin Grady I wouldn't marry her with a ten foot pole. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Only update modified fields
Norman Harman said the following: > Nobody knows me, so my opinion isn't worth much. But, this would be good. > Better would > be if it were transparent(properties or some other mechanism to notice when > fields are set > and therefore dirty/need updating). I'm fairly surprised something like this > isn't > already the default behavior. The newer patches on the ticket do what you describe - transparently track attribute changes and only include those which changed in the updates :) -- Collin Grady The most important service rendered by the press is that of educating people to approach printed matter with distrust. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Only update modified fields
Malcolm Tredinnick said the following: > See earlier threads for why transparent behaviour is not a very safe > idea. If you override save(), for example, it's going to be very easy to > end up with things not being saved. This is not common behaviour, so > asking somebody to at least pass in an extra param or two isn't going to > kill them. Actually in the previous thread you only seem to have mentioned overriding __setattr__ :) However, I'm sure the issue could be worked around (even though it seems pretty uncommon) - for instance, having __setattr__ create the dirty set when it doesn't exist, and only have the partial updates kick in if it does - so if you were to replace __setattr__ and didn't call the model's version, it would just revert to saving everything. -- Collin Grady I bought some used paint. It was in the shape of a house. -- Steven Wright --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Only update modified fields
Malcolm Tredinnick said the following: > The current latest patch fails in a dangerous way, which is why I'm > against it. Fail safely (so that my data always gets saved when I call > save()) and it's up for consideration. Is the failure you mention just the __setattr__ issue, or is there another issue you haven't mentioned? :) If that is what you're referring to, I'll get to work on fixing it :) -- Collin Grady Man's reach must exceed his grasp, for why else the heavens? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Adding SVN revision identifier to version
Deryck Hodge said the following: > Certain (older?) versions of the entries file are XML. We would need > to figure out how many versions there are, which doesn't do much for > future proofing us. Perhaps only fall back to the client if the 4th line isn't a rev #? -- Collin Grady Appearances often are deceiving. -- Aesop --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple PKs and "is_stored"
Russell Keith-Magee said the following: > On 8/31/07, David Cramer <[EMAIL PROTECTED]> wrote: >> Not only would this fix my multiple pk issue (temporarily :P) but it >> seems like the right approach. > > I'm not a big fan on making temporary fixes. To my mind, its better to > say 'this feature is coming' than have a halfway implementation that > breaks in various places (most notably, the admin app). The change he proposes would also break normal saving :) f = Foo(id=3, name="some new name") f.save() Would start throwing an exception since the row already existed but it would be trying to insert. -- Collin Grady Change your thoughts and you change your world. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: permission_required sends user to login, even if already logged in
Todd O'Bryan said the following: > Does anyone else wish that there were a setting for a PERMISSION_DENIED > page that the permission_required decorator could send users who are > already logged in to, rather than sending them to the login page? > > I'd still like users who aren't logged in to be sent to the login page. http://www.djangosnippets.org/snippets/254/ ? :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: mod_python documentation issues
Graham Dumpleton said the following: > FWIW, I believe the documentation should just say to always add both > parent and site. That way it properly mirrors what the development > server does. Doing that would avoid this whole argument as things > would just work like they did with the development server. Except that you do /not/ need to add the project directory to pythonpath, if you just reference everything properly and include the project name. If you always use project.app.whatever, your references won't break when you go from dev -> apache or such - the dev server allows a lot of relative things that it shouldn't. -- Collin Grady We are using Linux daily to UP our productivity - so UP yours! -- Adapted from Pat Paulsen by Joe Sloan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Visual recogintion of Django website
Mikkel Høgh said the following: > To illustrate my point, take a look at this image, a screenshot of a > very normal Firefox tab bar of mine: > http://mikkel.hoegh.org/galleries/odd_stuff/i_3_favicons?size=_original > It's much easier for me to find what I need by help of favicons - and > yes, most of the time, I have so many tabs open that I cannot see the > title of the web pages. Normally people don't pack tab bars that tiny though, so there would still be text to ID tabs by also :) -- Collin Grady Whom computers would destroy, they must first drive mad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Looking for discussion on #5535
Tom Tobin said the following: > *Way* -1. I don't want to be looking at code and wondering whether a > particular query is dealing with a local field named "foo_bar" or a > related model "foo" with a field "bar". Except when you do user__id it /is/ referring to the local column, it just magically drops the join on you, even though it looks like it will do one :) -- Collin Grady Save the whales. Collect the whole set. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Do you need more committers/triagers?
Yuri Baburov said the following: > 4) why it stopped other valuable changes of that part of code, like > aggregates support? > I just think you are trying to do much more than was necessary in that > branch. That's why it takes so long. Because there's no point doing the work on something that's about to be completely replaced - it's better to add it to the new code, so you only have to write it once. -- Collin Grady I'm not proud. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Looking for discussion on #5535
David Cramer said the following: > I don't believe .create() allows you to say myforeignkey=1, correct me > if I'm wrong, but I think it throws an error about it needing to be a > instance. But .create() already works with fkeyname_id, it's just get() and get_or_create() that don't :) -- Collin Grady BOFH excuse #150: Arcserve crashed the server again. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Looking for discussion on #5535
James Bennett said the following: > 1. The lookup syntax *always* uses double underscores for relations. But checking fkey_id isn't trying to cross the relation - it wants the local value :) > 2. The lookup syntax *only* lets you look up by things that actually are > fields. *cough* .get(pk=1) :) -- Collin Grady "MacDonald has the gift on compressing the largest amount of words into the smallest amount of thoughts." -- Winston Churchill --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Looking for discussion on #5535
Jacob Kaplan-Moss said the following:
> That is, make::
>
> Foo.objects.get_or_create(bar__id=1)
>
> Work the same way as::
>
> Foo.objects.get_or_create(bar__id=1, defaults={"bar_id": 1})
That would probably be better than the current, but I'm still on David's
side in thinking that allowing bar_id in get, create, and get_or_create
is far more consistent, since you can also use bar_id as a normal
attribute lookup and as a kwarg in making a model instance.
It just seems abnormal that it works everywhere /except/ .get() and
.get_or_create()
--
Collin Grady
Live within your income, even if you have to borrow to do so.
-- Josh Billings
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Looking for discussion on #5535
Gary Wilson said the following: > I say you are looking at it backwards here. It's not that get() and > get_or_create() don't work with fkeyname_id, it's that Model() and create() > don't work with fkeyname. I disagree strongly with that. It's already established that obj.fkeyname is the object, and obj.fkeyname_id is the ID, so why break that? It's far more consistent to just make fkeyname_id work in .get() and .get_or_create(), in my opinion. -- Collin Grady Don't let your status become too quo! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MEDIA_URL and trailing slash (documentation)
Deryck Hodge said the following:
> Another use case to consider:
>
> {{ MEDIA_URL }}{{ photo.get_absolute_url }}
>
> No way to avoid an extra slash if your get_absolute_url begins with a
> slash, which is common. I'm not passionate about what we recommend,
> but just wanted to remind that MEDIA_URL is not just used for
> get_FOO_url construction or for manually building urls.
That's not really a valid use case though - get_absolute_url should be
returning an absolute URL, not one relative to MEDIA_URL.
If your photo object involves a FileField or ImageField, it will already
be using MEDIA_URL in the get_fieldname_url function, so there'd be no
reason to attach it to MEDIA_URL after the fact.
--
Collin Grady
When you're ready to give up the struggle, who can you surrender to?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Looking for discussion on #5535
James Bennett said the following: > 1. It breaks consistency with how we currently do things I still disagree with you there. It would only break consistency if it was actually crossing the relation and checking the ID field of the other table. Since it is *not* a cross-relation lookup, not using __ syntax is *not* inconsistent. On the contrary, it now becomes *more* consistent with normal data access, such as obj.fkey_id > 2. What happens if somebody actually has a non-foreign-key field whose > name ends with the sequence "_id"? Then it finds that field as normal, and everything continues on. You'd only have to fallback to attname if you don't find a matching field name. -- Collin Grady "Life is too important to take seriously." -- Corky Siegel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Missing imports in sessions?
George Vilches said the following: > Can someone else verify this is a problem? I didn't think that os or > time was an implicit import. :) You're right, they're not :) -- Collin Grady I know things about TROY DONAHUE that can't even be PRINTED!! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Queryset in newforms
Mario Gonzalez said the following: > In my DB I've got lot of users, each one with different groups and > permissions, and I don't want to show them in my form. So, I want to > pass a parameter in form_for_model() and I wrote a patch for that: Just make your own formfield_callback, that's what it's for :) -- Collin Grady A boss with no humor is like a job that's no fun. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Queryset in newforms
Mario Gonzalez said the following: > I haven't seen this before, I'll try it but IMVHO it seems a hack > because you've got to generate a field and _then_ change the queryset. > I think the queryset must be defined once and not after. Actually, you don't - I just checked the formfield method of ManyToManyField, and you can pass the queryset directly to that, so it will use that when it generates the field instead of whatever it would normally default to. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Queryset in newforms
Mario Gonzalez said the following: > I should have to write the all callback and I think that's not what > I want. My proposal is if you've got a special queryset, just pass it > trough form_for_model() method only. Then you haven't got to re-write > all over again. Rewrite what all over? All you have to do is edit the generated field for your m2m field and change the queryset/choices. > Also, I don't want to change the field type, I just need a different > queryset. So far, Django not permit that(AFAIK) and I think this is > necessary. But what if you have multiple m2ms to multiple model types? Your proposal wouldn't support that - it would pass the same queryset to all of them, which is invalid. The proper solution for this is your own formfield_callback, not trying to make form_for_* handle one narrow situation so that you don't have to write one. -- Collin Grady Beam me up, Scotty! It ate my phaser! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Queryset in newforms
Mario Gonzalez said the following: > That's what I want to solve, give the opportunity to the programmer > to change the queryset easily when a form_for_model is needed but you > don't need the default queryset. I understand what you want, and you can do it with a formfield_callback! You do /not/ need some new, custom addition to form_for_model for this very, very narrow use-case. ### def my_callback(f, **kwargs): if f.name == "districts": kwargs['queryset'] = District.objects.filter(id__in=[1, 2, 3]) return f.formfield(**kwargs) MyForm = forms.form_for_model(Region, formfield_callback=my_callback) form = MyForm() ### And voila, now you have your queryset replaced. And this can be expanded quite easily to support multiple m2m fields or foreignkeys or whatever else you need to change, unlike your limited solution. So as you can see, the ability to replace the queryset already exists, and in a much better form :) -- Collin Grady The meta-Turing test counts a thing as intelligent if it seeks to devise and apply Turing tests to objects of its own creation. -- Lew Mammel, Jr. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Display name for Models in admin
sixpackistan said the following: > i apologize ahead of time if this seems like a stupid question- but i > have tried repeatedly to find an answer without having to post. > In any event, i have a model defined called 'ItemStatus' which is > displayed in the django admin as "Item statuss"- is there a way, short > of renaming my model class, to change how the model name appears in > the admin? This question is more suited for django-users - this list is for the development of django itself, not general help questions :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Another urlpatterns proposal (add method column)
tonnzor said the following: > As far as I see, reversing url is getting URL for a view. Then, if > view has only one route, there's no need to provide HTTP method. But > if there are > 0 routes to the same view, we can add optional METHOD > option. Or just make people use named URLs, which is already the solution for multiple routes to the same view :) -- Collin Grady When a person goes on a diet, the first thing he loses is his temper. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: OverflowError: mktime argument out of range
Please don't post questions to both django-users and django-dev. Django-users is for general help questions such as this, while django-dev is for discussion of the development of django itself, not help questions :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: shortcut to display one field from newforms
[EMAIL PROTECTED] said the following:
> 1) just form.FIELDNAME. It's quite obvious and is not occupied by
> anything.
Uh, yes it is :)
{{ form.foo }} prints the input for the foo field
> 2) form.show_FIELDNAME
> 3) form.show(FIELDNAME), where FIELDNAME is a string. But this one
> can't be used from templates, can it?
>
> Maybe there should be options for a person to choose from different
> methods to render the form, like:
> form.show_as_p_FIELDNAME
Seems like this would make more sense acting like the form generators if
anything, so it'd be {{ form.foo.as_p }} or such, instead of trying to
shove magic methods into the form class, it could just belong to the field.
> I think that this feature will be extremelly useful for people, who
> want their application to be ready as soon as possible, and who don't
> want to either insert chunks of repeating code into their templates or
> write custom inclusion tags.
On the other hand, it's kind of an edge case, since if you're using the
same set of tags for every field, it quite limits the amount of
customized layout you can do :)
--
Collin Grady
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
