Re: 1.2 Proposal: Database savepoint refactoring
On Tue, Aug 11, 2009 at 11:24 AM, Richard Davies < richard.dav...@elastichosts.com> wrote: > > Hi all, > > I've got two open tickets against database savepoints (#11156 and > #9205) and think this is an area which we should take a look at for > 1.2 - it is currently inconsistent, IMHO. > > I've no opinion on the Oracle issue but I do on the consistency issue. I don't agree the current savepoint use within Django is inconsistent. As far as I can tell, savepoints are used internally in the one case where Django itself catches and suppresses an IntegrityError. If there are other cases where Django internally prevents propagation of a database-level error to the application code without using savepoints to ensure that the connection remains in a usable state despite the error that has been hidden from the app, that would be inconsistent. But near as I can tell you are not pointing out any places like that? Rather the patch on #9205 strikes me as introducing inconsistency, unless you are telling me that it fixes ALL cases where an IntegrityError at the database level results in an an an unusable PostgreSQL db connection. Right now it is pretty simple: if your app code catches a database error it must do something to restore the DB connection to a usable state. With the patch for #9205 would we be able to switch that to state that the app code will never have to worry about clearing the error on the DB connection when it catches a database error? If not then we would have less consistency than before. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Why does Django make it hard to debug tags?
On Wed, Aug 12, 2009 at 8:03 AM, Russell Keith-Magee wrote: > > On Wed, Aug 12, 2009 at 9:45 AM, SmileyChris wrote: > > > > http://code.djangoproject.com/ticket/11461 > > > > DebugNodeList catches all exceptions, sticks them in a > > TemplateSyntaxError, and stuffs the original exception in the new > > exception. I'm not sure why this is done, but it breaks debugging and > > exception handling. > > > > What is the advantage of swallowing the exceptions? > > I can't speak with authority on the reason behind this, but if I had > to guess, I would say this might be a case of confusing intention with > accident. This behaviour has existed for at least as long as I can > remember, and it's been annoying for pretty much all of that time. > > To me, this points to a design decision that made sense in the early > days (pre-magic removal; maybe even pre public release). That decision > may have made sense with an earlier version of Django that didn't have > as much potential for exceptions in templates, but it is clearly > problematic now. > For whatever it's worth, the origin of this code is nearly four year ago on the new-admin branch: http://code.djangoproject.com/changeset/1046 >From the commit message there the intent was clearly to help, not hinder, template debugging. Things were quite different then, there was a TemplateDebugMiddlware added earlier on that branch: http://code.djangoproject.com/changeset/947 (where DebugNodeList was originally introduced) responsible for highlighting where the problems were for an exception. Before this code got back to trunk, the debug middleware was removed and special handling for template exceptions was integrated into the "new error pages": http://code.djangoproject.com/changeset/1299 That introduced get_template_exception_info, which we still have. The template debug code did not get to trunk via a branch merge but rather was individually moved over here: http://code.djangoproject.com/changeset/1379 I'm not sure at what point reporting of the original exception traceback was lost, but I thought I'd seen the details of the wrapped exception getting reported on debug pages -- long after these code changes since they were long before my time. Does that not happen any more? Or does that only happen some of the time? My guess is losing the original traceback wasn't an intentional thing. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: I want to know how to traversal all the urls in a django project?
Please don't crosspost to both django-users and django-developers. Pick the right list and post there, in this case -users. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: unicode user name
Please don't crosspost to both django-users and django-developers. Pick the right list (in this case -users) and post there. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.core.urlresolvers reverse, args and kwargs
On Sun, Sep 6, 2009 at 12:16 AM, vegas wrote:
>
> Hi guys,
>
> I was just doing some work, and I noticed that passing args and kwargs
> to reverse raises an exception which explicitly tells me not to do
> that:
>if args and kwargs:
>raise ValueError("Don't mix *args and **kwargs in call to
> reverse()!")
> I don't see an obvious reason for this to be the case, and looking at
> the end of the method, if search fails then a NoReverseMatch exception
> is raised with error text that leads me to believe that either at one
> point args and kwargs were mixable, or people would like them to be.
>
> I'm a far cry from a django developer, but I could probably rustle up
> a patch to make args and kwargs acceptable for reverse toward the end
> of next week if someone hasn't already done this and it's considered
> desirable.
>
>
Are you sure it is as easy as you think? This has been requested:
http://code.djangoproject.com/ticket/8764
and discussed:
http://groups.google.com/group/django-developers/browse_thread/thread/6356d87372352eab#
before. I don't get the idea it is that easy to do efficiently and without
confusing-for-users limitations on when mixing will and will not work.
Karen
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-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 -> admin_media Prefix Change
On Fri, Sep 11, 2009 at 9:40 AM, drozzy wrote: > > Just dug up a 2year old ticket on this: > http://code.djangoproject.com/ticket/2891 > > Can some core-developer modify the trunk or merge it in? > SmileyChris's patch looks good: > > http://code.djangoproject.com/attachment/ticket/2891/2891-backwards-incompatible.patch > > That ticket isn't open, it's closed wontfix: http://code.djangoproject.com/ticket/2891#comment:13 Do you have some reason to think Jacob's mind has been changed on this issue? Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Accepting foreignkey assignment by PK on QuerySet.update() (#11521)
On Fri, Sep 11, 2009 at 9:29 AM, Jerome Leclanche wrote: > > Could someone give some feedback on #11521? > (http://code.djangoproject.com/ticket/11521) > It's been sitting for almost 3 months without any kind of answer. The > current patch is a 2-line change which looks very reasonable, but I'd > love to be aware of any possible side effect of that change. > > Feedback from someone who isn't an ORM expert: Why doesn't it have a test? Mentioning in the description that the fix may be a hack might not have been the best idea. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Accepting foreignkey assignment by PK on QuerySet.update() (#11521)
On Fri, Sep 11, 2009 at 10:06 AM, Jerome Leclanche wrote: > > On Fri, Sep 11, 2009 at 5:03 PM, Karen Tracey wrote: > > Mentioning in the description that the fix may be a hack might not have > been > > the best idea. > > It's not "may", it's "I don't know". I'm not an ORM expert either, > hence the feedback request. > > Fixes presented with the statement "It may or may not be a hack" will likely take longer to get accepted. It's a clear signal to any committer not intimately familiar with the area of code in question that tackling that particular ticket will require doing some significant amount of investigation to verify that it is not in fact a hack fix or just symptom patching. Thus a statement like that likely limits the number of commiters who are going to look seriously at the fix to those who are experts in the area. (Or those who have some extra time on their hands and are interested in becoming an expert in the area.) I'm not suggesting presenting fixes as "surely right" when you are not in fact sure of that is a good idea. But if you are looking to move things along, doing some independent research into the code and perhaps verifying the approach taken in the fix is also used elsewhere, verifying that the full test suite runs correctly with the fix, etc. are things you can do and state in the ticket that might help with getting the fix accepted. I realize now you're looking more for feedback on the technical issues that may be associated with the fix but that wasn't clear to me from the first note, where it sounded like you could be looking for general feedback on why the ticket hadn't moved along. Sorry I can't provide feedback on the former but I did see some reasons for the latter so that's what I responded with. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: update_{FIELD_NAME} method to update only one field in a model.
On Wed, Sep 16, 2009 at 9:11 AM, Vladimir Prudnikov wrote: > Hello,The default behaviour for saving object is very hard for big models, > especially if it contain TextField. For example if I change one small field > in a model and that run save() method it will generate UPDATE query for all > of the fields which is very slow. > > There is an open ticket requesting this feature: http://code.djangoproject.com/ticket/4102 Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Distorted layout of this group in Google Groups
On Mon, Sep 21, 2009 at 10:53 AM, Léon Dignòn wrote: > > Hello, > > today I browsed to the group django-developers in Google Groups. The > navigation bar with the adverts, which is normally on the right side, > covers all the discussion topics on the left. The layout is broken, > but only in this group. In django-users everything is fine. > > Am I the only one with this problem? It's annoying because it covers > all the topics and also text of discussions. > > This appears to be some sort of google groups problem, that only affects some people some of the time (I've not seen it at all). See: http://groups.google.com/group/is-something-broken/browse_thread/thread/c73ae586c6fcef48/ Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Let's Talk About ``to_field``
On Wed, Sep 23, 2009 at 4:59 PM, David Cramer wrote: > > I haven't brought this up for quite a while, but ``to_field`` still > does not function properly (at least as of 1.1, I haven't noticed any > changes addressing it though). The issue is that anywhere you do a GET > lookup, it doesn't process the to_field properly:: > ># TODO: waiting on to_field fix >try: >opt = cls.objects.get(business=business.business_id, > key=key) >except cls.DoesNotExist: >opt = cls.objects.create(business=business, key=key, > value=value) > > That's supposed to illustrate the problem with to_field? It's a snippet of code lacking any context with a cryptic TODO comment. What is the model definition here (which would at least give a clue where to_field applies)? How would this code be different if this "to_field fix" were applied? This query: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=~to_field&order=priority shows 4 open tickets with the "to_field" in their summary. Is the problem you are referring to one of these? > This seems to have been solved in the admin branch when newforms-admin > landed, but seems mostly ignored in the core field's. This issue has > also existed as far as I can remember, which is quite some time :) > > I've not been around as long as you so without reference to a ticket or something unfortunately I have no idea what problem you are talking about. I also don't know what you mean by it being fixed in admin but not in "core fields". Admin doesn't define fields, so huh? I can't really parse what you are trying to say here. > So, what do we need to get the ball rolling on this. I don't have much > time myself to commit, but if it's minor things such as writing some > tests that easily reproduce all errors we've found. We'll glady commit > those. Other than though my day is just filled, but I'd love to see > this get fixed. It's something that's advertised as a core feature, > has been for 3+years, and simply doesn't work. > > The tests you mention filed in a ticket, or attached to one of those tickets from above if indeed one of those is reporting the problem you are talking about, would be helpful. If none of those tickets reflect the problem you are talking about, then a complete description of the problem would be helpful; as it is I have no idea what problem you are referring to. > On a side note, something that I also believe is a bug, is that > ManyToManyRel.get_related_field() returns the primary key field no > matter what. I'm not sure if thats the intended functionality of that > or not, but to me it sounds like this should refer to the field in the > through model (even if that model is virtual) that it's pointing to. > A filed ticket describing the problem and how to recreate it would have a better chance of getting remembered and fixed than a side note in an email. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Admin: TemplateSyntax error if I input a manual (and not existent) value in a FK in raw_id_fields
On Tue, Oct 6, 2009 at 1:24 PM, Marcob wrote: > > I saw these tickets: > > http://code.djangoproject.com/ticket/9484 (closed: duplicate) > Admin, raw_id_fields, not int value > Msg: #8746 covers this. > > http://code.djangoproject.com/ticket/8746 (closed: fixed) > Data entered in raw_id_fields needs better checking > Msg: Please file a new ticket for this > > http://code.djangoproject.com/ticket/11465 (closed: duplicate) > Broken representation of nonexisting objects for raw_id_fields > Msg: Duplicate of another ticket that reports this exact same thing > (and who's number I can't recall). > > It seems a catch-22 to me. > > Did I miss another "living" ticket? (it wouldn't be the first > time ;-) ). > > I can't find an open one that covers this (I would have thought it would have been fixed for #8746, but it wasn't) so I re-opened #11465. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Patch: adding a msg parameter to assertContains and similar methods in the test client
On Sat, Oct 10, 2009 at 8:21 PM, Russell Keith-Magee wrote:
> One thought that has occurred to me is that rather than using msg as
> the complete literal error string, we could use it as a prefix to the
> literal.
>
> i.e., to take line 124 that you used as an example:
>
> > def assertFormError(self, response, form, field, errors, msg=None):
> >...
> >self.fail(msg or "The field '%s' on form '%s' in context %d"
> > " contains no errors" % (field, form, i))
>
> would become:
>
> prefix = msg and "%s: " % msg or ""
> self.fail("%sThe field '%s' on form '%s' in context %d"
> " contains no errors" % (prefix, field, form, i))
>
> This preserves the best of both worlds - a rich failure message, plus
> the ability to add user-specific context to help identify the source
> of the problem in the test suite. This does differ from the behavior
> of the assert* functions in the standard library, but hopefully in a
> way that makes sense under the circumstances. Opinions?
>
I like this, except I'd rather give it a name other than msg since it does
act a bit differently than the msg argument taken by the Python assert*
methods.
Karen
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-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: Tutorial problem
On Sun, Oct 11, 2009 at 7:07 PM, Wolf.Halton wrote: > > Ticket #10050 (closed: fixed) > > Opened 9 months ago > > Last modified 3 minutes ago > Documentation bug in tutorial / admin manual? 'AdminSite' object has > no attribute 'urls' > > Here is what I need to ask. What trivial issue did I miss while doing > the dev/tutorial? presuming ubernostrum's response is accurate, then > I have missed something trivial that I cannot find. BTW, my admin > pages worked great until I started page 3 and added content to > urls.py Either I believe there is still an error in the tutorial, or > I made a trivial error that I need help with. Help! > If the admin worked fine and then broke during section three then you're likely hitting #11959, not #10050: http://code.djangoproject.com/ticket/11959 That one hasn't been fixed yet but the ticket description and attached diff hopefully will make it clear to you how to fix things so admin works again as you continue working through the tutorial. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Buildbot failure
I don't know who maintains or has access to the buildbot machine, but I can confirm the failure is due to leftover .pyc files. I saw the same thing on my own machine until I deleted all the .pyc files in the tree. Then it ran clean. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Oracle/GIS Testers Needed
On Fri, Nov 20, 2009 at 1:14 AM, Alex Gaynor wrote: > Hey all, > > Russ and I have been working on getting the multi-db work ready for > merge (final stretch here hopefully!), and I just ported the Oracle > backend to the slightly updated backend arcitecture so it could use > some testers. If you've got an Oracle setup and can run some tests > that would be great. You can grab the code here: > > http://github.com/alex/django/tree/multiple-db > > Make sure you use the multiple-db branch. I understand running the > tests under Oracle can be a bit slow, so perhaps start by just running > the "queries" tests, if they fail please reply with the complete > tracebacks and such here, otherwise if you have the time a shot at > running the full test suite would be great. > > The queries test ran OK once I removed: from django.db.backends.oracle import query from django/db/backends/oracle/base.py I guessed based on the fact that django/db/backends/oracle/query.py was removed in the last commit that the import was leftover from a restructuring. I am not sure but it looks like there may also be some other dead stuff referencing this query module (the query_class method in DatabaseOperations?), but I did not touch that, just removed that one import. I've got the full suite running now, but that will take a while. So far I am testing with just Oracle backend specified. The last time I tested this branch I also had a test config that specified multiple dbs -- a default and an extra one. Not sure if you wanted to test that at this point so I started with the simpler one. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=.
Re: Oracle/GIS Testers Needed
> > Just running the Oracle tests is enough for now. I've fixed the error > you spotted with the stray import left over and pushed that to github. > I get 6 failures and 26 errors but I do not know if any of them have anything to do with multidb. The output is here: http://pastebin.com/m2c763672 By contrast on trunk I get 7 failures and 26 errors: http://pastebin.com/mf7c57a6 The unable to create INITIAL extent errors are new -- I've not seen them before, but I am getting some on trunk as well as multidb (though more on multidb). I get the impression it may mean my install has some limits on how big things can grow, and tests are now exceeding those limits. Not sure, and I don't have time to spend on trying to figure it out right now. Nor do I have time to see which failure goes away with multidb, sorry -- so I figured I'd just post out the results and you can take a look if you think it would be useful. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=.
Re: Problem with history view in admin page
Note Oracle had the same problem: http://code.djangoproject.com/ticket/5087 I can't actually read Oracle but I think the fix involves adding a cast that extracts the first 4000 chars of data from the field for comparison. They override the field_cast_sql method in the Oracle DatabaseOperations to add the cast to any field type that ends with LOB. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=.
Re: Problem with history view in admin page
On Tue, Nov 24, 2009 at 7:09 PM, Russell Keith-Magee wrote: > This is a slightly moot point, though; Django defines the admin log > object_id using a TextField, and changing this would be a big > backwards incompatibility. > > Also I believe there's at least one other place in Django that does similar -- the object_pk in the base contrib.comments model is also a TextField. I suspect any DB backend that has trouble with the admin history view is also going to run into trouble with comments. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Conventions around plugable backends
I slightly prefer class-based configuration. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Ticket #399 -- bigint support
I think ticket #399 could make it into 1.2, but there's a -1 vote (from James) to overcome first: Patch on the ticket (which is over a year old) indicates how easy this is to do yourself if you need it. The patch is no longer a year old, it's been updated a few times recently, fixing tests to get it to work on multiple backends for instance. Yes, it's easy to do yourself. But to me this seems like an oddly basic type to be missing from the base, with enough users potentially wanting it that it deserves to be officially supported. So I'd be willing to spend some time on it, but I don't want to waste time if that -1 stands in the way of checking it in. James: how adamant are you on the -1? Would you consider -0 instead? Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #399 -- bigint support
2009/12/10 Tomáš Kopeček > > We've fixed all issues (like incomplete tests and few bugfixes), so > patch is now ready to be included into trunk. > > I partially agree with -1 vote. It is easy. What is against: Included in > trunk we address all backends (and it looks to be easy to maintain them) > and second point: we have some unit tests. > So finally I am more for inclusion than 'wontfix'. > > Actually, there is an issue related to "all backends" support. We can only add the necessary code for the backends that Django ships. There are also externally maintained backends, which won't support big integer fields without some changes. Currently, the behavior when using a backend that doesn't have a mapping for the new field is not ideal (I noticed this when trying out the patch that had a mistake in the sqlite mapping, resulting in sqlite having no mapping for the new field). Syncdb ran fine, but the table created was simply missing any big integer columns. I think it would be better if the syncdb failed with a clear message that the backend in use doesn't support that type of field. Now, it may be that from a practical point of view this will not really be a fix that is needed. If "old" external backends are going to fail loudly on 1.2 due to other core Django changes (I'm thinking multidb) then perhaps it will be clear to anyone using an external backend that a new version of it is needed for 1.2, and that new version would hopefully support the new field type. From a purist of view I still think syncdb should handle the situation better, but from a practical point of view its current behavior may not actually trip anyone up. And it's not really something I wanted to give a lot of thought to before determining whether this ticket can move forward. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: CRLF vs just LF in multipart parser
On Tue, Dec 15, 2009 at 7:33 PM, Dave Peck wrote: > Hello, > > I notice that Django's multipart form parser expects CRLF-style line > endings. Specifically, > django.http.multipartparser::parse_boudary_stream has a hardcoded > expectation of '\r\n\r\n' to end a part header. > > Is this line ending mandated by RFCs, or is this hardcoding a mistake? > > Reads like mandated to me: http://www.ietf.org/rfc/rfc2616.txt, section 3.7.2 (Multipart Types) http://www.ietf.org/rfc/rfc2046.txt Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #399 -- bigint support
I've uploaded what I think is a commit-ready patch for adding BigIntegerField. Barring any major objections I'd like to commit this in the next day or two. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Oracle 11g unicode test failure?
On Fri, Dec 18, 2009 at 5:44 PM, Ian Kelly wrote: > We just changed our test database to Oracle 11gR2 and discovered that > the unicode test case in the basic test is now failing. This may just > be something wrong with our installation, because we're seeing the > same problem performing the same test through sqlplus, whereas it > works agains Oracle 10g XE. It happens on two different 11g > databases, however, and I wanted to check whether anybody else with an > 11g database is seeing the same thing. > > The failure looks like this: > > File "/home/ikelly/projects/django.trunk/tests/modeltests/basic/models.py", > line ?, in modeltests.basic.models.__test__.API_TESTS > Failed example: >Article.objects.get(pk=a.id).headline > Expected: >u'\u6797\u539f \u3081\u3050\u307f' > Got: >u'\xbf\xbf \xbf\xbf\xbf' > > That is one of the errors I get on my Oracle 10g XE install. I always figured it was something misconfigured, but never tracked it down. (I know nothing much of Oracle but wanted a test install of it to make sure I didn't break anything when I was working on the transaction test speedup stuff for 1.1.) Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: MultipleHiddenInput outputs invalid HTML (#11843)
On Mon, Dec 21, 2009 at 11:12 AM, Tobias McNulty wrote: > http://code.djangoproject.com/ticket/11843 > > This is a simple fix to a rather bothersome problem; if you need to do > anything with those hidden inputs in JavaScript there's no way to uniquely > identify them without extending the widget and creating your own render() > (not to mention the fact that it's invalid HTML to begin with). Any chance > we could get it committed soonish? > > It sounds kind of like one I reviewed at the sprint so I might look at it soonish. I don't know how well my soonish matches yours, though. I've got virtually no time for Django work in the next week, so for me soonish would be next week at the earliest (and I've also got a bunch of other stuff people worked on at the sprint still in my queue to be looked at). Someone else could look at it, but the holidays combined with the major feature freeze deadline looming tend to make me think there isn't a lot of free time available right now for bug fixes. Some people are traveling and some are very focused on getting stuff done to meet the feature deadline. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feedback: Syndication feed views
> > (1) > http://code.djangoproject.com/attachment/ticket/12403/syndication-views-4.diff(Why > aren't my diffs showing? Are they too large for trac?) > > It's likely the six of these: \ No newline at end of file in the diff. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 1.2 Feature freeze
I'm listed as one of the interested committers on GSoC-6 (test improvements). Unfortunately I have not had time to devote to moving that along, and so far as I know nobody else has either -- I have not seen any activity or patches or discussion that would indicate anyone was hoping to get something done on it for the 1.2 feature freeze. So at this point I think it will have to wait for 1.3. (If I'm wrong and there is someone out there hoping to get something in by yesterday, please speak up...but I'm not going to have any time to look at anything related to it for at least a week, so unless there's another committer who can help with it, I think it's too late for it to make 1.2.) Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Design and code review requested for Django string signing / signed cookies
On Tue, Jan 5, 2010 at 11:53 AM, Elias Torres wrote: > > I'm not a security expert by any means, but I really the fact that > you're making use of HMACs in your design. > There seems to be a key word missing here: really the fact... (One might guess based on the rest of the message, but still it might be nice to know what was intended to go there.) Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: cached template loader is new in trunk/1.2, docs does not mention that
On Wed, Jan 6, 2010 at 12:16 PM, Jeremy Dunck wrote: > On Wed, Jan 6, 2010 at 10:24 AM, Amit Upadhyay wrote: > > http://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types, I > > looked and could not find "cached.py" > > in Django-1.1.1/django/template/loaders. > > There is a section for "django.template.loaders.cached.Loader". Isn't > that what you mean? > > I think the problem being reported is that is is not marked up as new in 1.2/Development version. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Requesting help - validation on inlineformset_factory instance with invalid data in email field hanging application.
On Fri, Jan 8, 2010 at 1:42 PM, Rebekah wrote: > I've searched but don't seem to see anyone else experiencing this > issue. I think it must be a django bug, I just want to know is this a > known issue, and if so, if there is a patch already in the works. > > I have a view which displays a form and inline formset for user and > profile model data. The problem I am having is with the email field > validation. For simple problems, it works just fine (e.g. entering > "becky" will return a validation error, but entering > "be...@example.com" is valid). But when I was testing, I discovered > that entering "be...@instansa.comm" causes the > application to hang, requiring a restart of the web server. There are > no errors, it just looks like it's stuck in a loop. This occurs > somewhere within the is_valid() call on the profile formset. > > What level of Django are you running? This sounds much like the problem that triggered the release of 1.1.1 and 1.0.4: http://www.djangoproject.com/weblog/2009/oct/09/security/ So if you are running anything earlier than those, the first step would be to update to a release that contains that fix. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: possible bug in model validation layer
On Sat, Jan 9, 2010 at 8:52 AM, Waldemar Kornewald wrote: > Hi, > the model validation layer checks for uniqueness of the primary_key > (in base.py: _perform_unique_checks()). But what if the pk value is > None (indicating for an AutoField that it should get an id from the > DB)? > > Currently, it still issues a DB query testing if there's an entity > with a pk of None/NULL. Do some DBs allow for a nullable pk or is the > query executed unnecessarily? > > Actually MySQL in some cases will return the last inserted row for that query, making that query a really bad idea. I have opened #12560 to track fixing this. Thanks, Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket resolved but not marked as such
On Sat, Jan 9, 2010 at 2:24 PM, aditya wrote: > From what I can see, the following ticket: > > http://code.djangoproject.com/ticket/4092 > > is addressing the same issue as this ticket: > > http://code.djangoproject.com/ticket/10969 > > > Ticket #10969 is closed, but ticket #4092 is still marked as "new". > Can we close #4092? > > Sure. When you see stuff like that feel free to just make whatever update seems right, in this case closing the one that was left open. Just be sure to note why in the ticket so it's clear to others that there is good reason for it to be closed now. If someone disagrees that the fix for the other ticket fixed this one they can always reopen and explain why. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Porting Django to Python 3
On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa wrote: > 2010/1/13 Tobias McNulty : > > I am by no means an expert on the matter, but I remember seeing a comment > > awhile back suggesting that it generally makes more sense to fix the 2to3 > > script than to maintain two branches of the same library. Might that be > the > > case here as well? > > Py3K does not support old-style classes. Django uses these quite a > lot, for instance the Meta-class of a model is old-style. I don't > think it is in any way possible to have an automatic script convert > these in a sensible way as django is deliberately utilizing the > difference between old and new style in no doubt a django-specific > way. If django on 2.x could be rewritten to no longer depend on > old-style classes, and was made to depend on python 2.6 or newer, then > 2to3 would have a chance to do its magic. > > I'm no expert either, but as I understanding it maintaining single source for 2.x (where x can be lower than 6) and 3.x and using 2to3 to generate the 3.x version during install may be a viable option. This is the approach that was taken by Martin v. Löwis when he got an initial port working back in late 2008: http://wiki.python.org/moin/PortingDjangoTo3k He cites bugs in 2to3 as a barrier to getting the approach to work at that time, but doesn't note anything insurmountable he ran across in the Django source. It is true the port only verified that getting through the tutorial worked, but that covers the basics of models certainly. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sessions: does set_expiry has a max value?
On Thu, Jan 14, 2010 at 10:50 AM, Pablo López wrote: > I *did* search in this group... not in others :-) > > Note django-users is the more appropriate group for this question. Questions about using Django should go to django-users, django-developers if for discussions focused on developing Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sessions: does set_expiry has a max value?
On Thu, Jan 14, 2010 at 11:07 AM, Pablo López wrote: > I know, but it looked a django bug, that is why I posted here, because > I think it makes more sense discussing about _potential_ django bugs > with their developers than doing it with their users. I'll search > better for next time. > > Note if you are quite sure you have found a bug, the right place to go is the tracker. Search there, and it you don't find that it has already been reported, open a ticket. There is no need to get clearance from the developer's list first (but please do search first). Most bugs don't require discussion on the dev list, it's only when the bug raises some design question that discussion might be taken to the list. If you aren't sure, the right place to ask is the user's list. You are not limiting your audience that way: far more people read -users than -developers, and core developers read and participate in discussions on the user's list. You may well get a quicker answer there than here. If it does seem like a genuine unreported bug someone will likely ask you to open a ticket in the tracker for it. This list: http://docs.djangoproject.com/en/dev/internals/contributing/#id1is useful for getting a sense of what is the preferred approach to use for various situations. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Porting Django to Python 3
On Thu, Jan 14, 2010 at 2:17 PM, Marty Alchin wrote: > 2010/1/14 Łukasz Rekucki : > > It is possible to write 3.x code that is backwards-compatible with > > python 2.6+. There are some rough edges like, names of stdlib modules, > > instance checks for strings and some introspection details. In my > > opinion, it's pretty much the same as supporting old 2.x pythons. > > In many cases, this is true, but there are other scenarios (certain > forms of exception handling, for example) where there is no syntax > that's valid in both versions. That's syntax, not just libraries and > functions. There's no way to even get a file to parse in both Python 2 > and Python 3 in these situations. There are certainly places in Django > that will run into these, so we really can't have a single codebase > that's completely compatible with both branches. > > Martin's approach was single codebase where the 3.x version for execution is generated by 2to3, not single source for execution across 2.x and 3.x. Thus I'm wondering if this difference is accounted for by 2to3? If yes, then it is not necessarily a problem that would stand in the way of maintaining single Django source and supporting Python 2.x and 3.x simultaneously. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pony request: refetch method to models
On Wed, Jan 27, 2010 at 12:17 PM, Alex Gaynor wrote: > I'm almost positive this is a dupe of another ticket, in the 3000-6000 > range I think. > The one I found was #901. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Getting Problem in connecting mysql (Help me please )
Please direct questions about using Django to the django-users list. django-developers is for discussion of developing Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Reg. Improving Django response time
Please ask questions about use of django on the django-users list. django-developers is for discussion of developing Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: problem with spatial data in sqlite
Please post questions about using Django to django-users. django-developers is for discussion of developing Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: HTML 5
On Sun, Jan 31, 2010 at 1:59 AM, Suno Ano wrote: > I see, I have not been aware any such discussion took place plus, > searching through the mail archives, issue tracker and wiki, there had > also been no sign of any such discussions/work in this regard. I just > wanted to know the status on HTML 5 which I now do. > There have been discussions on this mailing list before. See for example: http://groups.google.com/group/django-developers/browse_thread/thread/bbf75f0eeaf9fa64 (You probably want to search on things broader than just HTML5. That one I found searching in the Google groups interface on XHTML, since I recalled previous discussions of better support for HTML4/5 that also mentioned the current built-in bias towards outputting XHTML.) Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Help with Django model and 'choices'
Please post questions about using Django to django-users. This list is for discussion of developing Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Help with Django model and 'choices'
And now I see you posted there a couple of minutes before posting here. Please don't do that either. Choose the right list and post once. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #12760 is no dublicate
On Wed, Feb 3, 2010 at 3:21 PM, kanu wrote: > Hi, > > My Ticket http://code.djangoproject.com/ticket/12760 Titled : "related > models with Foreignkey.null=True must not get deleted on delete of > their relation" was marked as dublicate today. > > I don't aggree that this is a dublicate. i filed this as a bug not a > feature request. > The fact that you do not like the existing behavior does not make it a bug. There have been fairly extensive discussions on this list and in tickets on this subject; I'm reasonably certain from those that the existing behavior is in fact intentional. Many people don't like it. Supporting other behaviors is a feature request, already tracked by another ticket. I really think that it was intendet to not delete those relations. > e.g. the comments in CollectedObjects.add say : > # Nullable relationships can be ignored -- they are nulled out before > # deleting, and therefore do not affect the order in which objects > # have to be deleted. > > Even if it is not a bug the code appears a little confusing. > Why is a relation updated and afterwards deleted ? > >From my reading of that comment, it doesn't imply the objects won't be deleted. The code here appears to be concerned with generating the list of objects to be deleted in the appropriate order, and these don't affect the order. That's why they can be ignored here. I'd guess the nulling and then deleting in the "right" order is to enable deletions that would otherwise trigger integrity errors on some DBs, but I don't know enough about this code to say for sure. If you read through the related tickets I think you'll find suggestions for how to accomplish what you are looking for without actually requiring that it be implemented in the base. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 1.2 Beta Thursday
Is starting the deprecation process for something a feature or a bug? If feature, we should start the process for the psycopg1 backend (discussed here: http://groups.google.com/group/django-developers/browse_thread/thread/ac7874cac8ece97) before Thursday. Near as I can tell it hasn't been marked pending deprecation yet (but then, for the life of me I cannot figure out how to get pending deprecation warnings to display, so perhaps I'm missing something). Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Assertion Woes
On Fri, Feb 5, 2010 at 7:03 PM, FeatherDark wrote: > Good? :) > Just trying to help. > The errors sure felt real enough, I hope no one else has this problem. > Alex did not say the errors were not real, he said he doubted the problem is the fault of Django and was probably more likely a bug in the package you added -- meaning you'd likely have better luck moving forward on getting a fix by looking into the possibility of it being a bug in that package. In fact other people have had this problem, as a Google search reveals: http://sourceforge.net/tracker/index.php?func=detail&aid=2905909&group_id=78018&atid=551954 It sounds like the problem may be that a DLL is getting loaded twice, under slightly different names. Whatever code includes the assert thinks this may cause a problem, so it dies. Apparently removing the assert has worked as a fix for a couple of people. That may not be a good fix. A good way to proceed would probably be to follow-up on that ticket and see if you can get enough help there to identify what exactly is going wrong and where the fault lies. Starting with the code that is actually issuing the failing assert is likely to be more productive than starting with Django, because nobody who works on Django has a clue what that assert in some other code package is attempting to protect against or what Django (or your application code) might be doing to cause whatever is leading to the assertion failure. Whoever wrote the assert in the first place (or is currently maintaining that code) is far more likely to be able to give guidance on what might be causing the problem and how it might be correctly fixed. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12801 : Allow empty non-nullable ForeignKey fields until save()
On Mon, Feb 8, 2010 at 5:31 PM, Luc Saffre wrote: > [snip] Okay, it's obvious that Luke's and Luc's understandings of that problem > are quite different. We both explained our points of views. The next > step would be to hear other people's opinions. > I agree with Luke. I'm also puzzled by your resistance to utilizing the field with _id appended to access the "empty" value in cases where you don't want to deal with the possibility of a DoesNotExist exception. That field, the one with _id on the end, is the direct map to a column in the database. The other is a convenience for accessing the entire model instance that is the representation of a row from another table. If that row doesn't exist, it makes sense to me that attempting to access it, whenever, raises DoesNotExist. > I personally won't insist > further, especially since Luke knows Django better than me. May I > suggest again to mark this ticket to something different than "duplicate > of an invalid ticket"? > What difference does it make? Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12804 - decorating admin views marked as invalid
On Mon, Feb 8, 2010 at 8:44 AM, Luke Plant wrote: > What do people think? > Ugh. Assuming no one can come up with a brilliant fix so that the auto_adapt stuff can work when combined with arbitrary other decorators (I can't), I favor switching to a system that requires different decorators for methods vs. functions and documenting the backwards-incompatibility for 1.2. What you propose there reads pretty well to me. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.Auth
On Mon, Feb 8, 2010 at 6:39 PM, Vitaly Babiy wrote: > Hey Guys, > So 1.2 is almost out the door so I wanted to raise an issue that I would > love to start working to fix for 1.3. > Not to discourage you, but be aware the focus of most attention until 1.2 actually goes out is still 1.2. Feature freeze doesn't mean the release is done, it means attention shifts to bug fixing. You many not find many people ready to start thinking deeply about 1.3 just yet. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12801 : Allow empty non-nullable ForeignKey fields until save()
On Tue, Feb 9, 2010 at 3:02 AM, Luc Saffre wrote: > "Closed" as "Invalid", as I understand it, means that this ticket is not > worth to get more consideration and that further comments are not welcome. > > "Open" with a triage stage of "Someday/Maybe" would help people who > stumble on this behaviour to find our discussion. Especially if we add a > link to this discussion thread. > Open with a triage state of Someday/Maybe would imply that the current behavior has been acknowledged as wrong and that a change in the behavior might be expected. It would also imply that if someone provided a patch to change the behavior, it would have a chance of getting checked in. With two core devs stating they see the current behavior as logical and consistent and none stepping up to say the opposite, a change in behavior here isn't going to happen. Thus an open state for this ticket would give people the wrong impression of the state of the issue. Closed tickets are as easily found as open ones -- anyone doing research in an attempt to understand current behavior should not be limiting their searches to only open tickets. The right state for this ticket is closed, which means it's been reviewed and determined that the current behavior is correct and nothing needs to be done to fix it. I would not term further comemnts "unwelcome", but they are not particularly useful unless someone has some new light to shed on the issue. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: QuerySet.exists() - Possible bug?
On Wed, Feb 10, 2010 at 2:22 AM, Russell Keith-Magee wrote:
> It certainly doesn't look right; .exists() should be faster than
> .count(), and having all the extra columns in the query looks a little
> weird.
>
> However, to say for sure, we need a few more details:
>
> * Does this only happen when using David's devserver, or does it
> happen in a normal Django shell?
>
>
I can recreate with just simple shell queries and checking the sql in
django.db.connection
> * Can you give a *specific* example of a model and query that is
> causing this? Or, if it's happening in the process of running a
> management command or other Django-internal activity, what do you need
> to do to stimulate the problem?
>
Every exists() query I tried shows this behavior. For example:
>>> from django.contrib.auth.models import User
>>> User.objects.filter(username='kmt').exists()
True
>>> from django.db import connection
>>> connection.queries[-1]
{'time': '0.001', 'sql': u'SELECT (1) AS `a`, `auth_user`.`id`,
`auth_user`.`username`, `auth_user`.`first_name`, `auth_user`.`last_name`,
`auth_user`.`email`, `auth_user`.`password`, `auth_user`.`is_staff`,
`auth_user`.`is_active`, `auth_user`.`is_superuser`,
`auth_user`.`last_login`, `auth_user`.`date_joined` FROM `auth_user` WHERE
`auth_user`.`username` = kmt '}
>>>
>
> * Are you doing anything interesting with select_related() or
> anything like that?
>
>
No.
> * What version of Django (including SVN revision, if appropriate) are
> you using?
>
I tried current trunk and backed off to the changeset where the function was
added -- query was the same. Looking at the idiom it replaced, the extra
select of the constant 1 value as 'a' was followed by a values('a') that
turned the result into a ValuesQuerySet. I don't see where this is being
done with the exists() implementation. As a result it seems to be a regular
QuerySet with a query with default_cols=True, resulting in all the default
columns getting pulled into the query.
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django ignores generated name by custom storage when a callable upload_to is defined
On Fri, Feb 12, 2010 at 10:25 PM, Gleber wrote: > I don't know if this is a bug. If you are not sure it is a bug, the right place to ask is django-users, not here. See: http://docs.djangoproject.com/en/dev/internals/contributing/#id1 Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: INSERT INTO "db_model" ("id") VALUES (DEFAULT)
This list is for discussion of the development of Django itself. Please ask usage questions on django-users. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Serialization of single object instead of only querysets.
On Mon, Feb 15, 2010 at 9:08 PM, Gary Reynolds wrote: > There is already a ticket for this (and possibly others). > > http://code.djangoproject.com/ticket/11244#comment:4 > > It has been closed and marked wontfix, see the comments for why. I believe the request here is to reconsider that wontfix decision. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: non-english filenames broken on Windows after r10693
2010/2/17 Václav Řehák > the changeset 10693 fixing #11030 (File uploads break on non english > filesystem encoding) introduced a problem with non english filenames > in my setup (Windows XP or 2003, Python2.6, Apache). If I upload a > file with czech characters (e.g. čeština.txt - the first character is > ccaron or \u010d, the 3rd is scaron or \u0161) the file created on > Windows filesystem has a crippled name (ÄŤeština.txt). > > The problem is caused by smart_str converting the unicode string into > bytestring. If I revert 10693 and let the filename be passed to > os.open() as unicode string, the file is correctly created on the > filesystem. I think that smart_str should be called only if the > underlying filesystem cannot handle unicode characters in the > filename. > Please open a ticket. That fix looks wrong to me. We shouldn't be assuming the file system uses utf-8 encoding. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: File to object
Please ask question related to using Django on django-users, not here. This list is for discussion of development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Customize the browse button on image upload form
Please ask usage questions on django-users, not here. This list is for discussion of developing Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 404 debug pages should show the name of the tried urlpattern - #9310
On Thu, Feb 25, 2010 at 3:05 PM, SmileyChris wrote:
>
> But I do think it's critical to see a new 1.1 release before 1.2 is
> out - if for no other reason than having {% csrf_token %} in a 1.1
> official release.
>
>
Before 1.2 is out or at the same time as 1.2 goes out? We normally do a
final micro release for the previous release when a new release goes out. At
this point doing both that and a micro release to get {% csrf_token %} into
a 1.1.X release before 1.2 goes out strikes me as too many 1.1.X micro
releases too close together (assuming 1.2 goes out reasonably close to
schedule).
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal - admin actions with no elements selected
On Mon, Mar 1, 2010 at 6:59 AM, George Karpenkov wrote: > Thanks for the reply. > > If it wouldn't take too much time, can you please point me to those > discussions? > > This ticket is one I recall: http://code.djangoproject.com/ticket/10768 Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: problem in modeladmin response_action
On Mon, Mar 1, 2010 at 9:47 AM, Luca Sbardella wrote: > Hi there, > > I just switch from 1.2 beta 1 to svn version and the > ModelAdmin.response_action is not working as before Yes, this has been reported at least twice in the tracker (see http://code.djangoproject.com/ticket/12962) and at least once before on this list. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: jQuery with Django
Please send questions about using Django to django-users. This list is for discussions about developing Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: No module named project_name.settings
Please ask questions about using Django on django-users. This list is for discussion of the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: "ImportError: No module named django" with MacPorts
PLEASE direct questions about using Django to the django-users list. Usage questions are not on-topic for the django-developers list. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 2 small tickets
On Wed, Mar 3, 2010 at 12:33 PM, Jared Forsyth wrote: > As a general "best practices" question: When I update a ticket w/ a test > case and better patch, do I uncheck 'needs better patch' and 'needs > testcases'? Or do I leave that to the person who originally checked them? > If you believe you have addressed whatever made someone set "needs better patch" you should turn that off. Similarly if you have added what you believe are appropriate and sufficient tests, you should turn off "needs tests". Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: To Access SQL Reports from Django application
This question is off-topic for the django-developers list, which is a list about developing Django itself. Please ask questions about using Django on django-users. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django documentation for newer users
On Fri, Mar 5, 2010 at 11:35 AM, stherrien wrote: > What I'm suggesting is that we setup something to allow everyone to > improve the docs with help from the core django group. I think this > would be very helpful to everyone. if one of the core group would like > to help us get setup to do this it would be great. maybe if they setup > a repository with the current online docs online so we can add updates > as we do with django itself. > > Docs are already in the repository. If you've got an SVN checkout they're all in the docs subtree off the root. The tracker has a "Documentation" component. If you've got a specific suggestion for improvement, go ahead and make the changes in your local checkout, generate a diff as you would for code, open a ticket and attach the patch. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django documentation for newer users
On Fri, Mar 5, 2010 at 11:40 AM, Karen Tracey wrote: > ... open a ticket and attach the patch. > > And, as for all other tickets, it'll help if you search the tracker first and make sure that whatever ticket you're planning on opening isn't already open. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: django snippet marketplace
Please ask questions about using Django on django-users. The topic of this list is development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: process to access the SQL Server Reporting Services in the Django Application
Questions about using Django should be sent to django-users. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: multi natural_key dependencies problem
Please don't crosspost to both django-users and django-developers. Pick the right list and post once. This sounds like a usage question, so it belongs on django-users. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GSoC10 Idea: Additional queryset methods
On Fri, Mar 19, 2010 at 10:47 AM, Jacob Kaplan-Moss wrote: > On Fri, Mar 19, 2010 at 7:39 AM, Sh4wn wrote: > > I want to refactor the QuerySet and other databases related API's, > > which adds an additional method of selecting records, and provides > > more control of what data you'll select, but probably is a bit more > > complex than the current API. > > I don't want to discourage you, but... > > Wait. > > Actually, I *do* want to discourage you. [snip backwards compatibility > concerns] > It wasn't immediately clear to me that this proposal involved breaking backwards compatibility -- it sounded like it might just involve adding methods and not necessarily changing the behavior of existing ones. However, it does seem to be in direct conflict with the idea of getting to the ORM working on non-SQL databases. The additional methods mentioned (select, from, leftJoin) together all sound like they are moving the app-ORM interface closer to raw SQL rather than away from it. Given the more long-standing interest in getting the ORM working with things like app engine's BigTable, I can't see a proposal for movement more towards raw SQL being accepted. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Does Python 2.6.5 broke Django 1.1.1 Client Test?
On Mon, Mar 22, 2010 at 12:00 AM, Marcob wrote: > Please, does anybody know which patch I need to apply to 1.1.1 to fix > this strange problem? > Obviously (and unfortunately) I can't install 1.1.2 Alpha. > (A question like this more properly belongs on django-users.) While I can recreate your test failure with Python 2.6.5rc2 (I have not had time to install 2.6.5 final yet) and Django 1.1.1, the problem goes away if I run using a current SVN checkout of the Django 1.1.X branch. Sorry, I do not have any idea what change, specifically, is needed. I also have no idea what changed in Python that is causing the problem on 1.1.1. I've been running the Django tests using the beta/release levels of 2.6.5 and I never ran into this, so I don't think whatever change it was to Django was specifically in response to this problem. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Does Python 2.6.5 broke Django 1.1.1 Client Test?
On Mon, Mar 22, 2010 at 4:07 AM, Raffaele Salmaso < raffaele.salm...@gmail.com> wrote: > Marcob wrote: > > Please, does anybody know which patch I need to apply to 1.1.1 to fix > > this strange problem? > http://code.djangoproject.com/changeset/12807 ? > > No, turns out it was a change made farther back, and it was in fact a change specifically in response to the change in Python: http://code.djangoproject.com/changeset/11821 Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Passing context variables from template to view
The topic of this list is discussion of the development of Django itself. Please ask questions about using Django on django-users. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: High Level Discussion about the Future of Django
On Mon, Apr 5, 2010 at 10:35 AM, Dennis Kaarsemaker wrote: > Not a criticism per se, but I am wondering why the next 1.1.x is > released alongside 1.2 instead of as a release on its own. I've yet > again seen a case of python 2.6.5 breaking django tests, so I would > welcome a new release of 1.1.x a bit sooner than 1.2, if only from a > #django support perspective. > The problem is if we release Django 1.1.2 now, we still need another Django 1.1.X release simultaneously with 1.2 to package in an official release all remaining bug fixes backported to the 1.1.X branch before 1.2 is finalized. That would make for two very close together 1.1.X releases, which is generally not appreciated by users, though I realize it would be appreciated by early users of Python 2.6.5. Unfortunately the timing of Python 2.6.5 and Django 1.2 is a bit unfortunate here...for those who are quickly moving to Python 2.6.5 the best thing to do is run with a checkout of the 1.1.X branch. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Customizable error message for ``unique_together`` constraints
On Sun, Apr 11, 2010 at 11:10 PM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:
> On Mon, Apr 12, 2010 at 10:15 AM, orokusaki
> wrote:
>
> >
> > The only idea I have for a solution is:
> >
> >class Meta:
> >unique_together = (('account', 'name', 'You already have a
> > Widget with this Name.'),)
>
> [snip]
>
> That said - my initial reaction is that while I agree with the use
> case, I'm not a huge fan of the syntax - There is not syntactic
> separation between column names and error messages; while that isn't
> necessarily syntactically ambiguous, it's certainly conceptually
> ambiguous.
>
Agreed on the objection to that proposed syntax.
Just for reference, there is a ticket for customizable unique error
messages, #8913. Whatever is eventually done here needs to consider both
plain unique and unique_together messages -- the ticket at the moment only
seems to consider the former, but it would not make sense to add support for
that without also doing the unique_together case.
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django Newbie seeking for advice
Questions about using Django should be sent to django-users, not here. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ask for help about extending development on Django apps
This question should be posted to django-users, not here. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Long-running tests
On Fri, Apr 16, 2010 at 11:00 PM, Tom X. Tobin wrote:
> [snip details of run times]
>
> Sticking out like a sore thumb is API_TESTS under
> modeltests.fixtures.models.__test__, which clocks in at 1090
> seconds(!). The serializer tests also seem to take a pretty chunk of
> time at about 1-3 minutes each. I run the test suite fairly regularly
> (since we merge from upstream aggressively), and the total run time
> recently jumped from about 20 minutes to around an hour. Any ideas as
> to why these tests are taking so long?
>
>
The ones that are sticking out like sore thumbs have always been sticking
out like sore thumbs (on my slow machines). Whenever I glance at a test run
to see how it's going it's almost invariably "stalled" on one of those you
mention. And I know why. There are 10 of these:
>>> management.call_command('flush', verbosity=0, interactive=False)
for example, in modeltests/fixtures/models.py. That's a full re-build of the
entire test database. Many if not all of the others cited above have at
least one of those calls.
These are not new, so the question is why are you suddenly noticing them?
Did some recent change make re-syncing the DB even more expensive than it
used to be? Or has the number of test apps and model tables just been
growing, growing, growing slowly and now it's noticeably slower? You
mention, though, a recent jump from 20 minutes to an hour -- specifics on
what changeset(s), exactly, caused that dramatic difference in time might
give a clue.
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: help that Ip address can't be assigned-to
Please direct questions about using Django to the django-users mailing list. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Low-Hanging Fruit
On Mon, Apr 19, 2010 at 10:26 AM, Shawn Milochik wrote: > So, I'm asking for anyone in the core (or close to it) to specifically > point out any low-hanging fruit. Off the top of my head, a ticket I saw some activity on recently but have not had time to look into making a test/fix for: http://code.djangoproject.com/ticket/10523 Admin raises an exception if the repr of an object that is modified/deleted is greater than 200 characters. Fix is probably to truncate the object's repr to the max length of the field it's being put in. (Note this error will only happen for DBs that actually enforce max_length -- sqlite, for example, will happily let you store >200 chars in a field declared to only hold a max of 200. So the test for this will only fail on current code for certain DBs.) First place I'd likely look to put a test for this would be regressiontests/admin_views. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Running doc tests in Django's test suite
On Tue, Apr 20, 2010 at 3:44 PM, Anssi Kaariainen wrote: > I am trying to run some doc tests, but can't figure out how. > Specifically I would like to run the doc tests in regressiontests/ > forms/widgets.py. > > Running "./runtests.py --settings=test_sqlite forms" from the tests > directory it runs the unit tests (changing them results in failures) > but not the doc tests (no failures if changed). I have tried all kinds > of combinations like forms.widgets, forms.widgets_tests > forms.tests.widgets_tests as the last argument... but I just can't > figure out how to run them. So, could someone please help me? > > Oops. r12998 apparently broke the running of the forms doctests specified in tests.py, that's why you cannot get the widget_tests doctest to run. I've fixed this by reverting the r12998 change that caused this. ./runtests.py --settings=test_sqlite forms.widgets_tests should now run the tests you are looking to run. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Running doc tests in Django's test suite
On Tue, Apr 20, 2010 at 5:03 PM, Alex Gaynor wrote: > > Do you have any idea how that caused the fail, it should be completely > innocuous? > > I'm guessing it's got something to do with the ... at the beginning of the line making it appear to be a shell continuation line, not ellipsis for output checking. But why that has the ultimate effect of causing none of the doctests defined in the __test__ dictionary in forms/tests.py to run...I dunno. But they don't run with that change. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: format/input_format on timefield
The topic of this list is the development of Django itself: questions about how to use Django should be directed to django-users. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: sorl-thumbnail: random name in Thumbnail field
On Thu, Apr 29, 2010 at 11:57 AM, xRobot wrote: > > How can I do that ? > "How can I?" type questions should be sent to django-users. This list is for the discussion of the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: logging?
On Wed, May 5, 2010 at 12:46 PM, Kevin Howerton wrote: > What I was suggesting in my post though, was that we alter the default > CRITICAL error handling behavior ... as it stands (by default) all of > my ERRORs are being suppressed in production. This is pretty > confusing for new users (there were 3 others in IRC with the same > complaint yesterday), and pretty un-pythonic IMO. Unless I missed > something? > I think you are missing something. From your earlier note you seem to be saying that it is information your own code is writing to stderr that is getting lost somewhere. Django does nothing to suppress anything sent do stderr. I've got views that write to stderr running under mod_wsgi, and the stderr output appears in the configured Apache error log. You do need to either include a newline in the data or explicitly flush stderr for the data to be written, and that may be a difference from mod_python (I don't remember enough about mod_python to say one way or the other). I think the problem you are having is more related to mod_wsgi, and possible differences between it and mod_python, than Django. > At minimum the documentation should inform the user of this > short-coming, and provide a link to a wiki with the available > work-arounds. > It isn't clear to me what shortcoming you think should be documented. If it is the behavior of mod_wsgi with respect to stderr possibly the deployment docs for mod_wsgi could mention something, but one danger of Django putting information like this in the docs is that it gets out of date as mod_wsgi evolves. In general it seems better to provide a minimum amount of information in Django doc, stuff that is specific to Django, and point the user to the appropriate source for authoritative documentation on the 3rd-party package. For the record, Django's default handling of critical errors when DEBUG is False is fully documented: http://docs.djangoproject.com/en/dev/howto/error-reporting/ Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 1.1.2 admin form regression
On Tue, May 18, 2010 at 12:45 AM, SmileyChris wrote: > Can't investigate too much more until tomorrow, but it's a pretty big > regression so I thought I'd bring it up here for discussion as well as > starting a ticket. > > http://code.djangoproject.com/ticket/13556 > I cannot recreate given the information in the ticket. Admin validation of exclude is new and my first guess would be it's picking up a genuine error that has gone unnoticed before, but since the ticket does not include either the mode nor the model admin definitionit's hard to say for sure. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Default ordering on User model
On Fri, May 21, 2010 at 8:38 AM, tiemonster wrote: > Is there a reason that the default ordering on the User model is by > pk? Would it be a reasonable request to ask that the default ordering > for this model be username? I have several models that have a m2m to > the User model, and it's very hard to find someone to add using the > admin when the users are in pk order. I wanted to test the waters > before opening a ticket. > Actually there is no default ordering, and yes, there is a reason, see: http://code.djangoproject.com/ticket/6089, which also shows a workaround for getting ordering back for specific form fields. Granted that is a bit of a pain, and there is some dissatisfaction expressed at the end of the ticket, but I don't see a specific proposal for how to address the issue while still not introducing problem for sites with large numbers of users, so that's the way it is now. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Default ordering on User model
On Fri, May 21, 2010 at 8:46 AM, Jeremy Dunck wrote: > Even so, you could create a custom ModelAdmin for User, specifying the > ordering option: > > http://docs.djangoproject.com/en/1.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.ordering > > The default model admin for the User model already specifies ordering by username. The issue, I believe, is that that does not affect things like ForeignKey drop-down boxes. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Multiple apps in one view
Please send questions about using Django to django-users. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ANN: Django 1.2.1 released
On Mon, May 24, 2010 at 3:39 PM, Raffaele Salmaso < raffaele.salm...@gmail.com> wrote: > > but when the releases/1.2.X branch will be created? When it's needed. That is, when we get to the point of wanting to check in features for 1.3 that should not go into the next 1.2.X release. Until we get to that point, trunk essentially is the 1.2.X branch. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Trac version field
I've noticed a lot of people lately updating the trac version field of to be more recent. For example changing version from 1.0 to 1.2 or 1.1 to SVN. I thought this field was supposed to track the version against which a problem was written -- that is, the version of code in use by the reporter of the problem. When that is what is kept in the field, then version can be somewhat useful as an indication of (at least) how long a problem has been around. It's not perfect -- someone might be using 1.2 and notice a problem that has been around since day 1, but it is something. I'm not sure why people are feeling it is necessary or helpful to change this field? If a ticket was opened against version 1.1 and is still open, then we can reasonably assume that it's still a problem in 1.2 and current SVN. (If it is not, then the ticket should just be closed as fixed.) It's not necessary to update the version to reflect that an old still-open problem is still present in current trunk, and I see this kind of update as generally unhelpful since we lose easy access to the information that the problem is in fact long-standing and not newly-introduced. I find having some sense of hold old a problem is to be helpful when looking at fixing it, since if it is in fact new I'll probably try to figure out what has changed to cause the breakage whereas if it's been around forever I know that sort of investigation is not likely to be helpful. I don't see any place in the contributing doc that mentions what version is supposed to be set to, so perhaps my understanding of what it is supposed to be is just wrong. So I figured I'd post here and ask: what do others view as the purpose of this field? Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: django queryset issue
Please ask questions related to using Django on django-users. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: How to pass List to Form Meta Class
Please do not crosspost questions to both django-developers and django-users: pick the right list and send the question there. Questions about using Django, such as this one, belong on django-users. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Looking for Django vs. Joomla comparison
On Mon, Jun 14, 2010 at 1:59 PM, Hooshyar wrote: > I am new to this group, although I am 4 years old with Django. I have > a question. If this is not the right place, I apologize in advance. > Please refer me to a proper mailing list. Please reply here or you can > e-mail me directly, if you wish. my e-mail address is > hfn1...@yahoo.com > > django-users would be a better place to ask. This list is focused on the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ModelForms and ForeignKeys causing ValueError
On Mon, Jun 14, 2010 at 12:39 PM, Peter Bengtsson wrote:
> I'm happy to submit a ticket but wanted to check first that I'm doing
> the right thing. I think this used to work in Django 1.1 but not now
> in trunk.
>
> I can better explain it with code:
>
> [snip details]
> The point of this is that I can make an advanced search form where the
> form is just like the form for added one of these models. In my view I
> never call the save() method of the form instance.
>
> # tests.py
> class SimpleTest(TestCase):
>def test_model_forms(self):
>from forms import FooBarForm
>post = {'name':'Peter'}
>f2 = FooBarForm(data=post)
>self.assertTrue(not f2.is_valid())
>
>
> Instead of returning False on the is_valid() function, it raises a
> ValueError which looks like this:
>
> [snip details]
>
> I can understand that the field doesn't like having None set as a
> value because it will never allow the save but I'm not interested in
> saving here. I'm interested in getting a form that models (no pun
> intended) itself on a model.
>
>
> So, bug or feature?
>
Looks like a bug to me. is_valid() ought not be raising a ValueError...worst
case it should return False. But in this case True would seem to be the
correct answer, since you've set the field to not required.
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: [gsoc] app loading status + questions
On Tue, Jun 15, 2010 at 10:46 AM, Arthur Koziel wrote: > 4. Also in the same changeset, the 'nesting_level' and 'can_postpone' > variables were introduced. These fixed a problem where the package is still > being imported by Python and the model module isn't available yet. Again, I > couldn't reproduce this problem. Don't think I know anything about the other questions, but nested calls to load_app I've seen. See: http://code.djangoproject.com/ticket/13335 and its fix. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feature Request
On Mon, Jun 21, 2010 at 4:37 AM, Massimiliano della Rovere <
massimiliano.dellarov...@gmail.com> wrote:
> Anyway, my idea is the following:
> reference fields shown in the change list page (not change view) shown
> as links to the edit page of the instance.
> I tried to implement this on my own, specifying in display_list the
> name of an executable returning a link to the change page and settings
> executable.allow_tags = True, but doing so one cannot put this field
> in the list_filter tuple.
>
>
? You cannot put the callable you specify in list_display in list_filter,
but you can put the ForeignKey field itself. For example I have a model:
class FosterHome(models.Model):
name = models.CharField(max_length=64, unique=True)
caretaker = models.ForeignKey(Caretaker)
def caretaker_admin_link(self):
return u'%s' % (reverse(
'admin:ctrac_caretaker_change', args=(self.caretaker.pk,)),
unicode(self.caretaker))
caretaker_admin_link.short_description = 'Caretaker'
caretaker_admin_link.allow_tags = True
[other stuff snipped]
With admin definition:
class FosterHomeAdmin(admin.ModelAdmin):
list_display = ('name', 'caretaker_admin_link', 'count_foster_cats',
'best_phone', 'best_email')
search_fields = ('name', 'caretaker__name', 'cat__name')
list_filter = ('caretaker', )
inlines = [InlineFosterCat]
With this admin definition the Caretaker column in the change list page for
Foster Homes shows links to the edit page for the related Caretakers, and
there is a working "By Caretaker" filter on the right.
Given what you ask for seems to be easily implemented by existing admin
customization hooks I don't see the need for adding anything directly into
admin to support this.
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: How to options by limited_choices_to ?
Please send questions about how to use Django to django-users. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
