tickets

32,817 rows sorted by reporter

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: stage, status, type, severity, resolution, easy, has_patch, needs_better_patch, needs_tests, needs_docs, ui_ux, created (date), changetime (date), last_pulled_from_trac (date)

id created changetime last_pulled_from_trac stage status component type severity version resolution summary description owner reporter ▼ keywords easy has_patch needs_better_patch needs_tests needs_docs ui_ux
2834 2006-09-27 16:17:05 2006-10-14 13:00:00 2022-03-06 03:27:06.160724 Unreviewed closed Core (Other) defect minor dev wontfix Indents in base.py comments breaks epydoc doc generation. Running the [http://epydoc.sourceforge.net/ Epydoc] document generator on a model returns the following error message: {{{ File: c:\dev\python-2.4.2\lib\site-packages\django\db\models\base.py, line 243, in django.db.models.base.Model._collect_sub_objects Lines 246, 247: Improper paragraph indentation }}} Looking at those lines, we find: {{{ def _collect_sub_objects(self, seen_objs): """ Recursively populates seen_objs with all objects related to this object. When done, seen_objs will be in the format: {model_class: {pk_val: obj, pk_val: obj, ...}, model_class: {pk_val: obj, pk_val: obj, ...}, ...} """ }}} The problem appears to be with the extra tabs in the last two lines of that comment. I've fixed it in my local version, but someone may want to fix the version in the repository so it doesn't break for others. adrian     0 0 0 0 0 0
7308 2008-05-26 15:00:03 2008-05-26 20:06:15 2022-03-06 03:39:17.536864 Unreviewed closed Core (Serialization)     dev invalid (spam) (spam) nobody     0 1 0 0 0 0
9808 2008-12-11 23:36:41 2008-12-11 23:52:58 2022-03-06 03:45:44.102746 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9809 2008-12-11 23:49:16 2009-02-25 19:51:44 2022-03-06 03:45:44.256528 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9812 2008-12-12 05:41:56 2008-12-12 05:44:51 2022-03-06 03:45:44.699710 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9813 2008-12-12 05:41:57 2008-12-12 05:45:07 2022-03-06 03:45:44.853599 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9820 2008-12-12 15:19:20 2009-02-25 19:51:44 2022-03-06 03:45:45.775198 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9821 2008-12-12 15:19:22 2009-02-25 19:51:44 2022-03-06 03:45:45.909914 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9823 2008-12-12 20:02:32 2009-02-25 19:51:44 2022-03-06 03:45:46.183238 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9842 2008-12-14 07:45:08 2009-02-25 19:51:44 2022-03-06 03:45:49.331353 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9843 2008-12-14 07:45:13 2008-12-14 07:51:44 2022-03-06 03:45:49.517899 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9851 2008-12-14 23:28:18 2009-02-25 19:51:44 2022-03-06 03:45:50.758113 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9852 2008-12-14 23:28:18 2009-02-25 19:51:44 2022-03-06 03:45:50.917691 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9856 2008-12-15 06:49:43 2008-12-15 07:08:54 2022-03-06 03:45:51.553039 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9879 2008-12-18 00:18:37 2009-02-25 19:51:44 2022-03-06 03:45:54.876847 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9907 2008-12-23 19:26:44 2009-02-25 19:51:44 2022-03-06 03:45:59.039884 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9909 2008-12-24 22:07:08 2009-02-25 19:51:44 2022-03-06 03:45:59.320052 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9922 2008-12-28 20:25:26 2009-02-25 19:51:44 2022-03-06 03:46:01.078886 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
13373 2010-04-18 04:34:08 2011-09-28 16:12:23 2022-03-06 03:55:01.436676 Accepted closed Template system     1.2-beta fixed IF tag no longer short-circuits It looks like {% if %} with OR or AND no longer short circuits under 1.2-beta-1. class Page(models.Model): ... def beTrue(self): print "BEING TRUE" return True def beFalse(self): print "BEING FALSE" return False {% if page.beTrue or page.beFalse %} HELLO {% endif %} Under 1.1.1, using manage.py runserver, I will only see "BEING TRUE" printed for the above snippet. Under 1.2-beta-1, I see both BEING TRUE and BEING FALSE. Similarly, {% if page.beFalse and page.beTrue %} HELLO {% endif %} will produce only "BEING FALSE" under 1.1.1, but both BEING FALSE and BEING TRUE under 1.2-beta-1. nobody     0 0 0 0 0 0
3437 2007-02-06 00:11:36 2007-02-10 03:56:21 2022-03-06 03:28:42.709705 Unreviewed closed Core (Other)     dev fixed djang.http.HttpResponse logic for _is_string is invalid code currently does effectively thus- {{{ #!python if hasattr(content, '__iter__'): self._is_string = False self._container = content else: self._is_string = True self._container = [content] }}} Problem is that string objects support iteration. Fix for it's simple; just do {{{ #!python if not isinstance(content, basestring) and hasattr(content, '__iter__'): }}} (yes y'all prefer seperate patches, but it's a one liner ;) adrian (removed)   0 0 0 0 0 0
3438 2007-02-06 00:38:40 2007-02-26 06:16:19 2022-03-06 03:28:42.880972 Unreviewed closed Core (Other)     dev fixed django.db.models.base.__init__ refactoring Short version; for iteration over records, there model's __init__ is rather unfriendly to the way the args are passed in. At least for sqlite, the sql row is passed in as args- issue is that __init__ shoots through self._model.fields playing with kwargs prior, doing rather costly exception catching, pulling default values, etc, then *finally* does args processing. If you're dealing in one or two records, this doesn't show up much, but if you're dealing in 53k records (my usage is slightly weird admittedly), it's a pretty heavy slow down. attached is a patch to refactor __init__, knocking around a third off the __init__ cost via refactoring the args/kwargs processing, essentially reversing the actual flow while maintaining the same behaviour as before. Have been using it for a few days, and passes tests; comments welcome, mainly since I need to get this integrated for my uses. adrian (removed)   0 1 0 0 0 0
3439 2007-02-06 01:07:33 2007-02-26 03:42:25 2022-03-06 03:28:43.035759 Accepted closed Core (Other)     dev fixed django.dispatch.* is grossly slow Attached is a refactoring chopping off a good chunk of dispatch's overhead; hard to test it standalone, so testing was done for simple iteration over records and isolating the diff in the profiling for the refactoring. Short version, attached patch shows 5x boost in dispatch speed; for iteration (just that, no rendering) over 53k records, time drops from ~15.5s to ~11.6s just by cleaning up dispatch.* The internal data structs dispatch is using are still fairly innefficient- scaling will be an issue the more receivers there are for dispatched signals. So... can clean that up further, but there isn't any documentation re: the expectations of dispatcher. For example- order of connection to a signal, must the order be maintained for notifications at a specific sender/signal level? If I connect (in this order) func f1, func f2, both to object("foo") signal Any, must they be notified in order f1,f2? I realize pydispatcher is a seperate project- that said, they've already moved onto 2.0, and there are several 1.0.x's for pydispatcher released already- djangos' bundled copy is still at 1.0.0. Whats the intention? Intending on keeping it in sync, or is it just a fork point? Either way, the attached refactoring is not covered by tests at the moment- mainly since there are no tests in django for dispatcher. Would like to get feedback on the expectations of dispatcher (f1/f2 from above for example) prior to writing those tests, since the implementation (and google for that matter) lack any material on it. Finally, due to the massive number of calls to send (thus to getAllReceivers and friends), normal seperation (getAllReceivers using getReceivers for example) was intentionally broken down a bit- in other words, inlined a few functions. The codes invoked enough that the overheads seperation really isn't worth it, especially if you're not actually using signals for the most part (thus dispatcher is pretty much pure time waste). adrian (removed)   0 1 0 0 0 0
3441 2007-02-06 01:52:28 2007-02-06 14:01:13 2022-03-06 03:28:43.347673 Design decision needed closed Template system     dev fixed django.template.VariableDoesNotExist.__init__ prototype forces work to be done up front that is typically thrown away Kind of a cornercase, but VariableDoesNotExist derives from Exception, overriding nothing- meaning the str/repr for it must be done up front. Thus django.template.resolve_variable raises it via {{{ raise VariableDoesNotExist, "Failed lookup for key [%s] in %r" % (bits[0], current) }}} So... it's effectively raising VariableDoesNotExist(msg). Problem here is that a rather large amount of code just catches the exception, and substitutes a different value, TEMPLATE_STRING_IF_INVALID for example- in other words, they don't even *care* about the msg, the exception is just a passing mechanism. Thus the msg creation is pure overhead to most codeblocks I've found in django. Said overhead can add up; a context level lookup ( {{ foo }} for example), raising VariableDoesNotExist results in repr(context), repr'ing all mappings in context- if say your base template is just checking for a var, if so, outputing a queryset, else not outputting it, the current code forces a repr on context, in other words forcing the query to be executed. Which is fairly daft, if pretty much all code just throws out the exception, substituting a different value in. Attached is a patch changing VariableDoesNotExist's __init__ to (self, msg, params=()); via that, can delay the actual msg creation until it's required, making catching the exception just to substitute a different value far cheaper. Within the code, only resolve_variable throws the exception- google code search, nobody else is throwing it, thus it looks pretty safe to change the __init__ to delay the cost. Alternative, just derive NewStyleVariableDoesNotExist from VariableDoesNotExist, and have resolve_variable throw that; either way, it's work being done that isn't needed so should be tweaked. adrian (removed)   0 1 0 1 0 0
3449 2007-02-07 04:46:36 2007-02-09 22:09:08 2022-03-06 03:28:44.520999 Ready for checkin closed Testing framework     dev fixed rev 4460 test failures rev 4460 changed ChoiceField exception msg, but tests weren't updated... adrian (removed)   0 1 0 0 0 0
3453 2007-02-07 23:03:50 2007-09-21 04:00:33 2022-03-06 03:28:45.167371 Accepted closed Template system     dev fixed resolve_variable usage leads to redundant work Yet more refactoring ;) resolve_variable does a chunk of setup work for each invocation, checking for if the variable is a number, checking if its quoted (thus exempted from lookup rules), and finally splitting of the variable into it's component parts. The issue is that this work is utterly redundant the second time an attempt is made to resolve the variable- for loops for example. This patch splits out a Variable class which does the common setup work up once in init, with a resolve method to do the actual resolution against a context. The actual resolve is still a good chunk of time, but for my particular usage scenario (3 level deep for loop being the main cost), this shaves just shy of 25% of the runtime off via killing the redundant work. From a backwards compatibility standpoint, there isn't any issue- resolve_variable just becomes {{{ def resolve_variable(arg, context): return Variable(arg).resolve(context) }}} which admittedly will be slightly slower then whats in place now for simple lookups- this is offset by the greater efficiency of Variable usage within default tags/templates, and via killing off a quadratic op in resolve_variable- currently, it splits the arg, then does poplefts on the list. Problem there is that python lists are literal arrays; you delete the first item, every item after has to be moved one to the left, thus quad in execution. Fortunately var depth isn't usually deep enough for it to rear its head. jacob (removed) performance 0 1 0 0 0 0
3454 2007-02-08 03:36:26 2011-10-09 12:44:57 2022-03-06 03:28:45.316267 Accepted closed Database layer (models, ORM)     dev fixed sqlite backend is using row_factory when it should be using text_factory currently, sqlite has {{{ def utf8rowFactory(cursor, row): def utf8(s): if type(s) == unicode: return s.encode("utf-8") return s return [utf8(r) for r in row] }}} for row_factory; problem here is that it's rebuilding each record regardless of whether or not the utf8 conversion is required. doing {{{ Database.text_factory = lambda s:s.decode("utf-8") }}} limits the conversion to just TEXT objects. This is a bit faster; that said, I'm wondering why the forced conversion- sqlite stores data in utf8, if {{{ Database.text_factory = str }}} ware set, the whole decoding/encoding would be bypassed, and the native encoding (utf8) would be passed back. In terms of performance, using {{{ Database.text_factory = lambda s:s.decode("utf-8") }}} gains are dependant upon the column types; greater # of non-text fields, greater the gain. Real gain is via turning off the encode/decode and using str directly (underlying utf8); same gain in terms of avoiding extra inspection, but avoids all the extra work. Only downside to either change I can see is that raw sql queries would return str instead of sqlites unicode. Not really sure if this is an actual issue however (don't see any other such limitation in the backends). Patch is attached for the encode/decode variant; unless there are good reasons, would just bypass the encoding/decoding entirely. adrian (removed) unicode-branch 0 1 1 0 0 0
4441 2007-05-31 06:06:13 2007-05-31 15:32:37 2022-03-06 03:31:27.566700 Ready for checkin closed Template system     dev fixed minor regroup optimization For template tag such as {{{ {% regroup records by category as categories %} }}} the internal lookup/rendering is implemented as a var resolve of 'var.category', with the calling context dropped; in other words, code is forcing an uneeded lookup for every iteration of regroup; following patch cuts out the uneeded 'var.' lookup. adrian (removed)   0 1 0 0 0 0
4460 2007-06-02 04:37:32 2007-08-07 13:43:50 2022-03-06 03:31:30.967960 Accepted closed Testing framework     dev fixed runtests.py can't easily control which tests to run Right now, runtests.py accepts only model names to test- this isn't grand if you're specifically after running a regressiontest however, or even django.contrib.*. One can use trial, but that requires setting up a few extra envvars- it's not hard to do, it's just a fair bit of a hit to the workflow (at least it is for me). Attached is a patch mangling runtests.py so that it takes modeltests.model1, regressiontests.regresion1 args instead of just model names- additionally, can take modeltests.* or regressiontests.* to enable all tests for that namespace (basically). So for example- {{{ python tests/runtests.py --settings=settings -v 1 basic }}} becomes {{{ python tests/runtests.py --settings=settings -v 1 modeltests.basic }}} Upshot of that slightly larger invocation, is that regressiontests, django.contrib, any namespace can be specified now- {{{ python tests/runtests.py --settings=settings -v 1 regressiontests.bug639 python tests/runtests.py --settings=settings -v 1 django.contrib.sessions }}} adrian (removed)   0 0 0 0 0 0
4461 2007-06-02 12:20:15 2007-06-02 12:29:27 2022-03-06 03:31:31.143315 Unreviewed closed Template system     dev duplicate minor ForNode.render reversed optimization short version, nestled snuggly in django.template.defaulttags.ForNode.render is a homebrewed native reverse implementation; aside from it using range when it should be using xrange, this is fine for <py2.4; for >=py2.4 however, the builtin reversed should be used (fair bit faster among other things). So... attached is a patch doing just that. adrian (removed)   0 1 0 0 0 0
4462 2007-06-02 12:23:51 2007-06-10 03:11:11 2022-03-06 03:31:31.313858 Ready for checkin closed Template system     dev fixed minor ForNode.render reversed optimization short version, nestled snuggly in django.template.defaulttags.ForNode.render is a homebrewed native reverse implementation; aside from it using range when it should be using xrange, this is fine for <py2.4; for >=py2.4 however, the builtin reversed should be used (fair bit faster among other things). So... attached is a patch doing just that; for folks using >=2.4, it's a linear 10x boost (mass index lookups kill kittens when in combination with native py vs cpy speeds), so... worth adding. adrian (removed)   0 1 0 0 0 0
4506 2007-06-08 08:36:31 2007-06-24 12:38:11 2022-03-06 03:31:38.256396 Accepted closed Template system     dev fixed regroup should rely on __eq__ instead of repr Tucked away in django.template.defaulttags.RegroupNode.render is this lil gem- {{{ for obj in obj_list: grouper = self.expression.resolve(obj, True) # TODO: Is this a sensible way to determine equality? if output and repr(output[-1]['grouper']) == repr(grouper): output[-1]['list'].append(obj) else: output.append({'grouper': grouper, 'list': [obj]}) }}} re: the TODO... the answer is 'no'. Aside from the fact it's forcing 2(n-1) repr when n repr would suffice, equality protocol exists exactly for usage in cases like this. The repr abusage there covers up a few things- 1) bad object implementations that have taken the time to flesh out repr, but not __eq__ which isn't really covering up. Tough cookies frankly (__eq__/__ne__ are simple methods to implement, and are needed elsewhere- hashing for example). 2) Objects that repr to the same, but have an __eq__ that says they differ. If __eq__ says it differs, it differs- using an alt equality method is dodging whatever reason the original author had for having __eq__ compare differently (exempting if they just didn't implement __eq__, which is scenario #1). Either way, the extra repr calls aren't needed- more importantly, repr should *not* be used there. So... counter args? adrian (removed)   0 1 1 0 0 0
4521 2007-06-10 12:51:46 2007-06-15 00:05:36 2022-03-06 03:31:40.934004 Ready for checkin closed Core (Other)     dev wontfix signals should have __(str|repr)__ for debugging/maintenance. django.dispatch.dispatcher.An(y|onymous) singletons derive from a 'Parameter' class, basically providing a default __repr__, docstring. Useful for those signals, but should be generalized so that it's usable for other custom signals for any poor folks trying to yet again optimize dispatch :) Attached is a patch adding a custom _signal class; it's not required for creation of a specific signal to connect to, merely advisable- adds in __str__/__repr__ automatically (and docstring if supplied) making things a bit simpler for folks debugging. adrian (removed)   0 1 0 0 0 0
4523 2007-06-10 14:20:10 2007-06-17 01:31:12 2022-03-06 03:31:41.254618 Design decision needed closed Template system     dev duplicate NodeList.render cleanup Tucked away in !NodeList.render is a fun little isinstance check, basically {{{ if isinstance(node, Node): bits.append(self.render_node(node, context)) else: bits.append(node) }}} With the render method being a hook method for derivative classes to intercept exceptions, and add some debugging info in; two limiting points to scaling there[[BR]] 1) Because !ForNode uses it to store strings, the isinstance is required- no other code uses it for this functionality, making me think !ForNode shouldn't be forcing !NodeList to do something odd, should do the job itself[[BR]] 2) Because !DebugNodeList overrides render_node, instead of render, an extra func call is involved for every node; again, single usage slows down the common usage. So... question is, why should !ForNode use it? Have yet to find any comments/explanation code wise, only thing I can *guess* is that someone was trying to extend !DebugNodeList.render_node behaviour down through a for; as said, this hurts the common case. Realize the first reaction is likely going to be another "micro-optimization is evil" comment; thing is, while it's not a huge gain like say removing dispatch.send invocations from Models.*, it's a constant waste occuring in any !NodeList.render (which are common enough). Usual usage scenario I'm abusing for testing pegs it as a constant 1.4s hit against trunk 64s (26s if using my misc patches sitting in tickets); might not seem like much, but it's yet another spot where it's spinning it's wheels without reason. So... why is !ForNode abusing !NodeList here? Oversight? Worth preserving? adrian (removed) performance 0 1 0 0 0 0
4561 2007-06-14 14:39:28 2008-08-06 15:32:46 2022-03-06 03:31:47.627762 Ready for checkin closed Core (Other)     dev duplicate dispatch refactoring Original ml discussion is [http://groups.google.com/group/django-developers/browse_thread/thread/1491d45d193ed111 here]. Short version; dispatch is a slow beast- basic design flaws follow * signals are sent regardless of whether or not something is listening * every emit/send requires searching for any matching sender, and matching signal receiver- additionally, requires looking up Any. The listeners change only when a new connection is added/goes out of scope, doing it every time at send is inefficient * signals, while singleton instances, aren't used for anything more then effectively a constant; meaning all of the logic is shoved into dispatcher; due to this, there is no easy place to define the set of args sent to listeners, it's completely dependant on each send invocation using an adhoc agreed to standard. Due to a signal being just a constant, there is no easy space to make signals faster via calculating up front the receivers to notify (it could be implemented in dispatcher.*, but that code is already ugly/messy, and feels a bit fragile). Attached is a patch adding the basic intelligence to signals; this folds in ticket #4521 (basic signal class with __str__/__repr__). Roughly, adds the following logic: * for 'smart signals' (signals that are more then just constants), adds (enable|disable)_sender(sender) methods. In dispatcher.connect, if the signal is 'smart', signal.enable_sender(sender) is invoked- basically notifies the signal that something is actually listening, and what specifically is listening. In disconnect, a amtching disable_sender(sender) is added- same thing (notify that a receiver is going away). * Tracking of all known 'smart signals'; this is used by Any, to multiplex enable_sender calls down into each individual signal * a pre/post signal class, and func to generate the paired signals. This one is a bit more complex, and is the initial gain (aside from cleanup )from this refactoring. Basically, it modifies the sender on the fly, injecting pre/post dispatch… nobody (removed) performance 0 1 0 0 0 0
4563 2007-06-14 16:27:47 2007-12-02 23:57:23 2022-03-06 03:31:47.919727 Ready for checkin closed Template system     dev fixed Context should expose removed/added scope objects (dicts) Originally suggested it [http://groups.google.com/group/django-developers/msg/987347b0da607839 in the 'ForNode multiple args' thread], but opening a ticket for it now since it's generally useful. Basically, proposing that Context.(push|update) return the newly added scope, and that Context.pop() returns the removed scope (for reasons of API symmetry mainly). The main reasoning behind this is that it's useful to bypass Context when doing more then setting a key or two- Context's api isn't as full featured as dicts (nor necessarily should it be). Right now, can do similar tricks via passing in the new scope to update, but that's not particularly friendly/obvious- alternative being reaching into the Context internal stack, which again, isn't very friendly (screws encapsulation anyways). Bypassing context for doing scope updates is actually fairly useful- very least, access to .clear() is a nice way to avoid continual pop/push on the stack per iteration. nobody (removed)   0 1 0 0 0 0
4565 2007-06-14 19:00:15 2007-07-14 09:45:53 2022-03-06 03:31:48.202110 Design decision needed closed Template system     dev fixed template rendering should yield items, not concat strings at each level Given following template- {{{ {% for x in blah %} {% for y in x %} {% bunch o nodes %{ {% endfor %} {% endfor %} }}} The way the template rendering subsystem works, each 'bunch o nodes' is added onto a list w/in 'for y', then collapsed into a string, and returned to 'for x'; which builds up a list, collapses it down into into a string, and returns it. Problems follow: * wind up continually generating larger and larger strings as data is added on, percolating it's way up to the actual template.render. This isn't totally friendly to performance (specifically has a knack for forcing the alloc pool to expand repeatedly). * Data is already ready to be sent, but it's locked away in the template- basically, template rendering tries to build a final string of all contents- until that's finished nothing is sent * Said "final string of all content" means that django winds up being more memory hungry, pretty much without any reason. A backwards compatible solution is the introduction of an iter_render method to Node, that yields finalized chunks as they're available- this doesn't mean yielding each char as it's available, means (for a ForNode for example), yielding each chunk of data for iteration; via this approach, Template.iter_render has chunks of data percolate up as they're available, instead of just one big ass string at the end. Attached is a patch implementing iter_render, and converting existing tags/templates/involved codepaths over to iteration where sane; some node rendering still collapse internally (filter expressions primarily, although will be targeting those later). This patch includes the patch from ticket #4523 (isinstance usage there gets ugly when a lot of items are passing through it). Final other change worth noting- changes the base http so that it's no longer flushing after every single write during content dumping. Reason behind this should be fairly obvious- fine if you're writing a single item, sucks if you're writing a few hundred. One point of potent… adrian (removed) performance 0 0 0 0 0 0
4625 2007-06-19 19:53:16 2007-06-22 08:39:51 2022-03-06 03:31:58.412720 Unreviewed closed Template system     dev fixed NodeBase metaclass check logic is faulty As hinted at on the ml, the NodeBase.__new__ code is a bit faulty- {{{ def __new__(cls, name, bases, attrs): """ Ensures that either a 'render' or 'render_iter' method is defined on any Node sub-class. This avoids potential infinite loops at runtime. """ if not (isinstance(attrs.get('render'), types.FunctionType) or isinstance(attrs.get('iter_render'), types.FunctionType)): raise TypeError('Unable to create Node subclass without either "render" or "iter_render" method.') return type.__new__(cls, name, bases, attrs) }}} Failings: 1) for code that has already broken the iter_render/render cycle, each derivative *still* has to assign a render/iter_render else it'll invalidly explode 2) no way to disable it (intermediate direct descendants from Node, say, adding helper functionality- they expect render/iter_render to be overriden, but the rules don't apply to them). Attached is a patch that converts the check over to verifying the resultant (as in, full MRO) render/iter_render, and adds an option to specifically disable the verification where needed. adrian (removed)   0 1 0 0 0 0
4779 2007-07-06 00:13:49 2011-10-09 12:44:57 2022-03-06 03:32:34.997120 Unreviewed closed Testing framework     dev fixed typo in tests Willing to bet the commiter of this didn't win the spelling bee as a kid ;) Attached is a simple 3 line correction; basically tests are asserting Response == Reponse, simple typo. adrian (removed)   0 1 0 0 0 0
5106 2007-08-06 23:10:56 2007-08-20 03:40:18 2022-03-06 03:33:33.410276 Design decision needed closed Database layer (models, ORM)     dev fixed django.db.backend.*.base refactoring Splitting connection pooling up into two patches; this particular ticket holds refactoring of django.db.backend.*.base.DatabaseWrapper classes to remove redundancy, and give an easier spot to control connection pooling. Very least, the misc backend implementation are a bit redundant- deriving from a common base class is a bit saner in this case for debugging and extension reasons. mtredinnick (removed)   0 1 0 0 0 0
9989 2009-01-08 09:57:31 2011-09-28 16:12:21 2022-03-06 03:46:11.403197 Accepted closed Core (Other)     1.0 fixed removal flaw in django.dispatch.Signal.disconnect Eyeballing cleanup in signals, spotted a bit of whackyness trying to cleanse a list via enumerate usage; presume the author tried removing from the list directory (which blows up since that invalidates the listiter) and came up w/ this instead. Flaw with it is that enumerate continues to increase the index even if you change the list under it's feet- in other words, you skip the item immediately following a deletion. One reason list comps are usually better in this case (although dependant on # of items and deletions of course). So... that should be using list.remove and catching ValueError where it doesn't exist. Quite a bit faster due to shifting comparison to cpy, and stopping the search after the first find. Clarifying the latter, a quick read of Signal.connect shows it disallows redundant connections to the same 'key'; meaning that the enumerate code in place right now is daft for continuing it's search for more to wipe- essentially a mismatch between connect/disconnect (guessing it crept in when someone tweaking signal.connect to disallow redundant registrations). basically convert {{{ for idx, (r_key, _) in self.receivers: if r_key == lookup_key: del self.receives[idx] }}} into {{{ try: self.receivers.remove(lookup_key) except ValueError: pass }}} 'nuff said. nobody (removed)   0 0 0 0 0 0
16763 2011-09-08 00:25:25 2011-12-02 16:41:11 2022-03-06 04:04:04.492772 Accepted closed *.djangoproject.com Bug Normal   fixed code.djangoproject.com won't stop emailing me (doesn't abide by cc/reporter/etc) As the summary says, I've long since moved on from django; this includes de-cc'ing myself basically every where I could find. That said, code.djangoproject.com persists in emailing me. Examples being #17, #3544, #4102, #3529. Basically anywhere I've commented- I get notification. If I uploaded a patch, I get notification. If I cc'd myself, than de-cc'd myself, I get mail. Further kicker is the stupid thing is bound to my email address rather than my user account (hell if I know why), so it's not even picking up my account's email being set to noreply@djangoproject.com (yep, that's rude, but it's been pissing me off for a while now). I'd be significantly less annoyed if it were just emailing me for tickets I've filed (bugzilla behaviour), but this is /not/ the behaviour I've observed; as said, check the tickets, none of them have me cc'd, couple of them the only thing I ever did was cc myself, than remove it later on. Still I get mail. Kindly sort it or point out exactly how I'm being stupid and could suppress this myself (procmail wiping it on my side does not fly- I'd sooner set a forward than go that route). nobody (removed)   0 0 0 0 0 0
28407 2017-07-18 07:22:42 2018-03-12 18:13:02 2022-03-06 04:48:38.750433 Accepted closed Database layer (models, ORM) New feature Normal 1.11 duplicate Allow inspectdb to introspect db column comments when use inspectdb make model from db. the db column is created by dba, not developer . so db column comments set to models Field is helpful for developer. like {{{ field = models.IntegerField(blank=True, null=True) #comments in db }}} [https://github.com/django/django/pull/8770] nobody 007gzs db comment 0 1 0 1 0 0
31293 2020-02-21 05:45:47 2020-02-28 14:05:12 2022-03-06 04:56:14.665155 Ready for checkin closed HTTP handling Cleanup/optimization Normal dev fixed MultiPartParser support double quotes Although the rfc2231 document does not indicate that values can be wrapped in double quotes. However, some third-party tools wrap the value in double quotation marks when wrapping HTTP requests (such as the filename of the file uploaded by PostmanCanary). This results in double quotes for the filename at the end of Django parsing. Postman request body: {{{ ----------------------------677822685948106391633425 Content-Disposition: form-data; name="file"; filename="测试.txt"; filename*="UTF-8''%E6%B5%8B%E8%AF%95.txt" Content-Type: text/plain test ----------------------------677822685948106391633425-- }}} django got filename is `测试.txt"` not `测试.txt` This is not a bug of Django. But I suggest Django do some compatibility processing. CPython is also compatible with this situation. [https://hg.python.org/cpython/file/default/Lib/test/test_email/test_headerregistry.py] [https://github.com/django/django/pull/12485] 007gzs 007gzs   0 1 0 0 0 0
31307 2020-02-25 00:24:56 2020-02-28 06:40:21 2022-03-06 04:56:16.782941 Ready for checkin closed contrib.admin Bug Normal dev fixed Arrow display error in filter_horizontal field when width less than 1024px when screen width less than 1024 filter_horizontal field add and remove arrow display error when mouse hover 007gzs 007gzs   0 1 0 0 0 1
31449 2020-04-10 05:56:05 2020-04-10 06:05:36 2022-03-06 04:56:38.087932 Unreviewed closed contrib.admin Bug Normal dev duplicate Autocomplete doesn't work when ForeignKey to_field is not pk. if a ForeignKey field with to_field (not pk), and the field set to autocomplete_fields. form will get pk not to_filed_value when edit model in change_view. example: ObjectC field a in AutocompleteSelect will got pk not code. save fail models: {{{ class ObjectA(models.Model): code = models.CharField(verbose_name='code', max_length=32, unique=True) name = models.CharField(verbose_name='name', max_length=32) def __str__(self): return self.name class ObjectB(models.Model): name = models.CharField(verbose_name='name', max_length=32) a = models.ForeignKey(ObjectA, on_delete=models.CASCADE, related_name="+") ma = models.ManyToManyField(ObjectA) def __str__(self): return self.name class ObjectC(models.Model): name = models.CharField(verbose_name='name', max_length=32) a = models.ForeignKey(ObjectA, on_delete=models.CASCADE, to_field='code', related_name="+") ma = models.ManyToManyField(ObjectA, through='ObjectCtoA') def __str__(self): return self.name class ObjectCtoA(models.Model): c = models.ForeignKey(ObjectC, on_delete=models.CASCADE, related_name="+") a = models.ForeignKey(ObjectA, on_delete=models.CASCADE, to_field='code', related_name="+") class Meta: auto_created = True }}} admin: {{{ class AdminA(admin.ModelAdmin): list_display = ('id', 'code', 'name') search_fields = ('code', 'name') class AdminB(admin.ModelAdmin): list_display = ('id', 'name', 'a') autocomplete_fields = ('a', 'ma') class AdminC(admin.ModelAdmin): list_display = ('id', 'name', 'a') autocomplete_fields = ('a', 'ma') site.register(models.ObjectA, AdminA) site.register(models.ObjectB, AdminB) site.register(models.ObjectC, AdminC) }}} nobody 007gzs   0 0 0 0 0 0
31462 2020-04-13 23:55:47 2020-04-15 07:11:37 2022-03-06 04:56:39.924797 Ready for checkin closed contrib.admin Cleanup/optimization Normal dev fixed Allow overridding widget in formfield_for_manytomany(). It does not work when I set `widget` param to function `formfield_for_manytomany()`. This is different from the `formfield_for_foreignkey()` function. 007gzs 007gzs   1 1 0 0 0 0
31853 2020-08-05 05:39:39 2020-08-05 08:28:08 2022-03-06 04:57:41.940227 Ready for checkin closed contrib.admin Bug Release blocker 3.1 fixed Incorrect wrapping of translated action labels in admin sidebar for East Asian languages. [[Image(https://code.djangoproject.com/raw-attachment/ticket/31853/0.png)]] nobody 007gzs   1 1 0 0 0 1
31856 2020-08-05 09:18:37 2020-08-05 09:34:34 2022-03-06 04:57:42.430846 Unreviewed closed contrib.admin Cleanup/optimization Normal 3.1 invalid Add block to customize nav_ sidebar style and script.   007gzs 007gzs   0 1 0 0 0 0
31884 2020-08-14 03:19:02 2020-08-18 09:28:31 2022-03-06 04:57:46.374693 Unreviewed closed contrib.admin Cleanup/optimization Normal 3.1 wontfix nav-sidebar ui optimization 1：toggle-nav-sidebar will got a black border after click in chrome; [[Image(https://code.djangoproject.com/raw-attachment/ticket/31884/1.png)]] 2：content will Out of screen when nav-sidebar is open [[Image(https://code.djangoproject.com/raw-attachment/ticket/31884/2.png)]] nobody 007gzs   0 0 0 0 0 0
31901 2020-08-19 00:38:11 2020-09-02 13:18:52 2022-03-06 04:57:48.737648 Ready for checkin closed contrib.admin Bug Normal 3.1 fixed Content will out of screen when nav-sidebar is open Due to the ambiguity in the handling of buttons in question 1 of ticket_31884, the priority is now to fix problem 2 [[Image(https://code.djangoproject.com/raw-attachment/ticket/31884/2.png)]] 007gzs 007gzs   0 1 0 0 0 1
31876 2020-08-10 18:38:23 2020-08-10 18:51:13 2022-03-06 04:57:45.296922 Unreviewed closed contrib.auth Bug Normal 3.1 invalid UserManager._create_user does not respect USERNAME_FIELD In the default UserManager, create_user and create_superuser do not respect USERNAME_FIELD. nobody 0az   0 0 0 0 0 0
10003 2009-01-09 22:59:23 2009-01-09 23:31:34 2022-03-06 03:46:13.536753 Unreviewed closed Template system     1.0 invalid if and extends in template {{{ {% if mobile %} {% extends 'base_mobile.html' %} {% else %} {% extends 'base_normal.html' %} {% endif %} }}} Throws following exception: {{{ Exception Type: TemplateSyntaxError Exception Value: Invalid block tag: 'else' Exception Location: /home/dsduser/django-synble/django/template/__init__.py in invalid_block_tag, line 333 }}} I think this should be supported. Second option is to write include correctly so that include does not broke inheritance. E.g.: basbase.html: has block base.html: include "basebase.html" logic.html: extends "base.html", inheritance of basbase.html block does not work here anymore. nobody 0ptr   0 0 0 0 0 0
29751 2018-09-12 05:51:23 2018-09-12 16:54:12 2022-03-06 04:52:04.028126 Unreviewed closed Migrations Bug Normal 1.11 duplicate Saving deserialized objects in custom migration fails in certain cases Saving deserialised objects in custom migration fails in certain cases (model has new fields added since) because `_get_model` used [[https://github.com/django/django/blob/b9cf764be62e77b4777b3a75ec256f6209a57671/django/core/serializers/python.py#L91|here]] uses the latest version of the model (rather than the migration-specific model, which is derived using `apps.get_model` where `apps` is the first argument passed to a custom migration function - which is passed to `migrations.RunPython`) Fix here would be to pass the `apps` received as first argument in a custom migration via the `**options` in `deserialize()` 0xKD 0xKD serialize,deserialize,migration 0 0 0 0 0 0
13180 2010-03-23 03:07:13 2010-03-23 11:15:00 2022-03-06 03:54:29.101125 Unreviewed closed Template system     1.1 worksforme html template links broken the problem isn't with the python code, it's with the html templates. I have a site that checks if someone is logged in and if not provides the following link: "/accounts/login". Everything is works until I press the login link. nothing happens. The url at the top of the screen changes and even if you try to refresh after the url has changed nothing happens. The source is fine: I checked it. I would think this problem was my fault, but when you type in "/accounts/login" yourself it works fine. Because of this I assume he problem is rooted in the HTML and template system. nobody 114fc69b8e6e93c0447be8de link href html broken 0 0 0 0 0 0
31834 2020-07-27 19:49:41 2020-07-28 13:51:43 2022-03-06 04:57:38.645535 Unreviewed closed Migrations Bug Normal 3.0 duplicate Cannot sqlmigrate on Django migrations that change unique_together Somewhat similar to #26624, but forward sqlmigrate, reproduced on Django 3.0.8 and Postgres 10.x. If a model has a unique_together of {{{ unique_together = [ (a, b) ] }}} and it becomes {{{ unique_together = [ (a, b, c) ] }}} , although the makemigrations command successfully generates a new migration with the corresponding AlterUniqueTogether() operation, the migration cannot be inspected with the sqlmigrate command. Reproduce bug with the following (the project may also be attached) {{{ class Model1(models.Model): id = models.IntegerField(primary_key=True) name = models.CharField(max_length=255, unique=True) class Model2(models.Model): id = models.IntegerField(primary_key=True) link_id = models.CharField(max_length=255) settings = models.ForeignKey(Model1, on_delete=models.CASCADE) class Model3(models.Model): id = models.IntegerField(primary_key=True) order = models.IntegerField() model_2 = models.ForeignKey(Model2, on_delete=models.CASCADE) direct = models.BooleanField(default=True) class Meta: unique_together = [ ('model_2', 'order') # To get the bug, change this to ('model_2', 'order', 'direct') and sqlmigrate the migration that this creates. ] }}} The error shown in the terminal is: {{{ Traceback (most recent call last): File "manage.py", line 22, in <module> execute_from_command_line(sys.argv) File "/lib/python3.6/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line utility.execute() File "/lib/python3.6/site-packages/django/core/management/__init__.py", line 395, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/lib/python3.6/site-packages/django/core/management/base.py", line 328, in run_from_argv self.execute(*args, **cmd_options) File "/lib/python3.6/site-packages/django/core/management/commands/sqlmigrate.py", line 30, in execute return super().execut… nobody 1337 sqlmigrate 0 0 0 0 0 0
20106 2013-03-21 12:17:37 2013-03-21 12:53:45 2022-03-06 04:13:03.918219 Unreviewed closed Python 3 Cleanup/optimization Normal 1.5 invalid A little optimazon--"0 errors found" When I ran "python manage.py validate", it gave me "0 errors found". I think it should be "0 error found". Thanks. nobody 1458409827@qq.com   1 0 0 0 0 1
20259 2013-04-14 13:36:21 2013-04-15 12:08:09 2022-03-06 04:13:26.913519 Unreviewed closed Documentation Cleanup/optimization Normal 1.5 invalid Syntax Error in the Document I found a mistake in the document(http://media.readthedocs.org/pdf/django/1.5.x/django.pdf), on page 486: "but in views written by hand you’ll need to explicitly use RequestContext To see how that works, and to read more details, check out Subclassing Context: RequestContext.", I think there should be a dot after "use RequestContext". Thanks. nobody 1458409827@qq.com   1 0 0 0 0 1
28165 2017-05-03 10:10:23 2017-06-07 21:09:08 2022-03-06 04:48:06.057938 Accepted closed File uploads/storage Bug Normal 1.11 fixed FileExtensionValidator's allowed_extensions must be given in lower case Using any uppercase character for an 'allowed_extension' prevents it from being matched. Because the input filename is being lowered before comparison to the extensions. Here is an example: {{{ #!python from django.core.validators import FileExtensionValidator from collections import namedtuple valid = FileExtensionValidator(['pdf', 'png']) File = namedtuple('File', ['name']) # valid: different case in file name named_file = File(name='myfile.PDF') valid(named_file) named_file = File(name='myfile.PdF') valid(named_file) # using uppercase in validator valid = FileExtensionValidator(['PDF', 'PNG']) # invalid: everything, because the case of the input is lowered named_file = File(name='myfile.PDF') valid(named_file) # ValidationError: ["File extension 'pdf' is not allowed. Allowed extensions are: 'PDF, PNG'."] named_file = File(name='myfile.pdf') valid(named_file) # ValidationError: ["File extension 'pdf' is not allowed. Allowed extensions are: 'PDF, PNG'."] }}} nobody 153957 validators filefield 0 1 0 0 0 0
27619 2016-12-21 09:01:28 2016-12-21 12:49:23 2022-03-06 04:46:42.091584 Unreviewed closed Database layer (models, ORM) Bug Normal 1.10 duplicate Queries where column name includes a '%' character break when using MySQL Sorry about this nonsense, but... I have a table in MySQL with a column name '%exp'. I know this is a poor choice for a column name. When calling the objects.all(), I was getting a rather frustrating error message from pyMySQL, "not enough arguments for format string." I couldn't figure out what was causing it until I printed result of calling QuerySet.Query.sql_with_params() on the resulting QuerySet. I saw that there were no params, but the string contained %e, which python interpreted as trying to format the string. nobody 16zzundel5   1 0 0 0 0 0
26943 2016-07-23 17:27:58 2016-07-25 00:32:14 2022-03-06 04:45:06.620980 Unreviewed closed Documentation Uncategorized Normal   invalid Link with BooleanField explanation not available I just an old project to updated to django 1.7 and happened to get this link: HINT: Django 1.6 changed the default value of BooleanField from False to None. See https://docs.djangoproject.com/en/1.6/ref/models/fields/#booleanfield for more information. But this link is dead. Where can I find the information? nobody 1kastner   0 0 0 0 0 0
24467 2015-03-10 16:51:09 2015-03-12 00:19:12 2022-03-06 04:27:43.258625 Ready for checkin closed contrib.admin Bug Normal dev fixed jQuery error in Django admin site when use "get_prepopulated_fields" I have Django ModelAdmin for Blog model. {{{ class BlogAdmin(BaseModelAdmin): fieldsets = [ (None, {'fields': ['name', 'description', 'slug']}), ('Date information', {'fields': ['date_create', 'date_change']}), ] # NOTE: this work well # prepopulated_fields = {"slug": ("name",)} def get_readonly_fields(self, requets, obj=None): """ Disable edit slug field for object. """ if obj: return self.readonly_fields + ('slug',) return self.readonly_fields def get_prepopulated_fields(self, requets, obj=None): """ Prepopulate slug field only for new object. In out case we always return value that I mentioned above for "prepopulated_fields". """ return {"slug": ("name",)} admin.site.register(Blog, BlogAdmin) }}} '''What do I do?''' I try to show prepopulate field ONLY on create new object page. When we edit this object - I disable option to edit slug field and show it as read-only. When I use "prepopulated_fields" all work as expected. When I switch to use custom method "get_prepopulated_fields" the jQuery error appear in web browser console: {{{ TypeError: undefined is not a function (evaluating '$(field.id).data('dependency_list', field['dependency_list']) .prepopulate(field['dependency_ids'], field.maxLength)') }}} As I found - the error appear because it's not defined "prepopulate" function: {{{ >>> django.jQuery("#id_slug").prepopulate undefined }}} Who knows how to fix this? nobody 1st   0 1 0 0 0 0
25198 2015-07-30 16:07:59 2015-08-07 11:04:50 2022-03-06 04:40:29.309898 Unreviewed closed Core (Serialization) Uncategorized Normal dev needsinfo Django's model_to_dict should return ALL fields, including hidden Hello. I found that Django return only editable fields in call of `model_to_dict`. I wish to have an option `include_hidden=True` to get list of ALL fields including not editable ones. I will make this fix and tell you about fix. nobody 1st model serialization 0 0 0 0 0 0
20829 2013-07-30 14:57:34 2013-08-16 19:23:12 2022-03-06 04:14:53.901828 Accepted closed GIS Bug Normal 1.5 fixed Geodjango and PostGIS Exception Error I have connected an existing POSTGIS database and when I run inspectdb I get Exception: Could not find a geometry or geography column for "raster_columns"."extent" nobody 2059016j@student.gla.ac.uk   0 1 1 1 0 0
21531 2013-11-29 13:48:45 2013-12-31 11:38:15 2022-03-06 04:16:46.730351 Accepted closed Forms Bug Normal 1.6 invalid Django 1.6 forms.SlugField validation error Hi, I have a problem with SlugField. In my model I have this field: slug = models.SlugField(_(u'Slug'), blank=True, null=True) Adding an item through admin, django catches this error: Django Version: 1.6 Exception Type: AttributeError Exception Value: 'NoneType' object has no attribute 'strip' Exception Location: myvirtualenv/lib/python2.7/site-packages/django/forms/fields.py in clean, line 1142 Is this a bug or my fault? I tried the same code with django 1.5.5 and it works. Thanks nobody 20tab   0 0 0 0 0 0
2582 2006-08-21 21:23:03 2006-08-22 17:45:22 2022-03-06 03:26:26.279905 Unreviewed closed contrib.admin defect normal dev fixed verbose_name can't contain quote (' ") symbols seems that ''/media/js/SelectFilter2.js'' contain some bug, that doesn't give us ability to use quotes in verbose_name. When we define verbose_name (in ManyToMany field) as {{{ verbose_name = ' "Read also" block ' }}} classic field view in admin pannel defined by {{{ filter_interface=models.HORIZONTAL }}} brokes just to one many-select HTML field. adrian 235 verbose_name 0 0 0 0 0 0
2583 2006-08-21 21:35:44 2009-11-06 16:39:03 2022-03-06 03:26:26.454506 Unreviewed closed contrib.admin defect normal dev worksforme can't use ForeignKey in list view (class Admin: list_display) If we'll use next code: {{{ class Articles(models.Model): .... author = models.ForeignKey(Authors, blank=True, null=True, verbose_name='Автор статьи') #models.CharField('Автор статьи', maxlength=100, blank=True) .... class Admin: list_display = ('pub_date', ... 'author') }}} The list view of objects will be broken in header - there would be no header for this ForeignKey. In ''django/contrib/admin/templates/admin/change_list_result.html'' defined: {{{ <th{{ header.class_attrib }}> }}} and actualy it renders into (with ''TEMPLATE_STRING_IF_INVALID = "TEMPLATE_STRING_IF_INVALID"'' in settings.py): {{{ <thTEMPLATE_STRING_IF_INVALID> }}} ForeignKey field lacks this attribute nobody 235   0 0 0 0 0 0
2584 2006-08-21 21:49:40 2007-01-30 22:03:59 2022-03-06 03:26:26.597979 Unreviewed closed Database layer (models, ORM) defect normal dev worksforme no MySQL codepage select Django works '''only''' with utf8 codepage in MySQL, it's great problem with using it in others codepages. In ''django/db/backends/mysql/base.py'' hardcode defined MySQL codepage. {{{ if self.connection.get_server_info() >= '4.1': cursor.execute("SET NAMES utf8") }}} There only one possibility to change it manualy. Other variant is to move this option out to ''settings.py'' as MYSQL_CODEPAGE or try to extract this data from DEFAULT_CHARSET, as it was recommended on local forum: {{{ from django.config import settings ... if self.connection.get_server_info() >= '4.1': cs = settings.DEFAULT_CHARSET.replace('-', '') cursor.execute("set character set %s" % cs) }}} adrian 235   0 0 0 0 0 0
11270 2009-06-06 08:30:14 2011-09-28 16:12:21 2022-03-06 03:49:31.719309 Accepted closed Core (Cache system)     dev fixed Cache templatetag with memcached can't handle long tags similar to #10016 Memcached has a hard limit of 250 characters for cache keys. So we have to use md5 hash instead of the whole cached tag name with all vary variables. {{{ Traceback (most recent call last): File "/var/www/virtual/sumno.com/modules/django/core/handlers/base.py", line 86, in get_response response = callback(request, *callback_args, **callback_kwargs) File "/var/www/virtual/sumno.com/htdocs/sumnocom/apps/lib/decorators.py", line 56, in wrapper return func(request, *args, **kwargs) File "/var/www/virtual/sumno.com/htdocs/sumnocom/../sumnocom/apps/generic_content/views.py", line 370, in detail_view_content_entry context_instance=RequestContext(request)) File "/var/www/virtual/sumno.com/modules/django/shortcuts/__init__.py", line 18, in render_to_response return HttpResponse(loader.render_to_string(*args, **kwargs), **httpresponse_kwargs) File "/var/www/virtual/sumno.com/modules/django/template/loader.py", line 107, in render_to_string return t.render(context_instance) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 176, in render return self.nodelist.render(context) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 768, in render bits.append(self.render_node(node, context)) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 781, in render_node return node.render(context) File "/var/www/virtual/sumno.com/modules/django/template/loader_tags.py", line 97, in render return compiled_parent.render(context) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 176, in render return self.nodelist.render(context) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 768, in render bits.append(self.render_node(node, context)) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 781, in render_node return node.render(context) File "/var/w… nobody 235   0 1 0 1 0 0
12425 2009-12-22 17:21:39 2011-09-28 16:12:23 2022-03-06 03:52:31.020800 Unreviewed closed Translations     1.1 fixed Typo in the Ukrainian translation really nasty typo in variable name in message translation: in django/conf/locale/uk/LC_MESSAGES/django.po 'min' variable in message was replaced by 'max' that that was causing server error 500: {{{ File "/var/www/virtual/sumno.com/modules/django/forms/fields.py", line 155, in clean    raise ValidationError(self.error_messages['min_length'] % {'min': self.min_length, 'length': value_length})  File "/var/www/virtual/sumno.com/modules/django/utils/functional.py", line 222, in __mod__    return unicode(self) % rhs KeyError: u'max' }}} jezdez 235   0 1 0 0 0 0
25252 2015-08-09 20:48:32 2015-08-31 05:15:58 2022-03-06 04:40:36.927604 Accepted closed Database layer (models, ORM) Cleanup/optimization Normal 1.8 fixed Add a friendly error message when using Queryset.select_related() after values() Trying to use a queryset while using both methods 'values' and 'select_related' will throw an error when trying to use iter. models: {{{ class Poll(models.Model): name = models.CharField(max_length=50L) class Entry(models.Model): poll = models.ForeignKey(Poll) name = models.CharField(max_length=50L) }}} code: {{{ >>> iter(Entry.objects.values('name').select_related('poll')) }}} error: {{{ Traceback (most recent call last): File "<console>", line 1, in <module> File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/query.py", line 162, in __iter__ self._fetch_all() File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/query.py", line 965, in _fetch_all self._result_cache = list(self.iterator()) File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/query.py", line 1085, in iterator for row in self.query.get_compiler(self.db).results_iter(): File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 794, in results_iter results = self.execute_sql(MULTI) File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 829, in execute_sql sql, params = self.as_sql() File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 378, in as_sql extra_select, order_by, group_by = self.pre_sql_setup() File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 48, in pre_sql_setup self.setup_query() File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 39, in setup_query self.select, self.klass_info, self.annotation_col_map = self.get_select() File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 207, in get_select klass_info['related_klass_infos'] = related_klass_infos TypeErr… Y3K 2roy999 queryset values select_related 1 0 0 0 0 0
32024 2020-09-21 15:07:15 2020-09-21 16:18:26 2022-03-06 04:58:07.215052 Unreviewed closed Uncategorized Bug Normal 3.1 invalid AttributeError: 'tuple' object has no attribute 'startswith' manage.py@dev > makemigrations ssh://root@10.32.109.197:22/proj/env/bin/python3 -u /root/.pycharm_helpers/pycharm/django_manage.py makemigrations /proj/app/mysite File tracking disabled Migrations for 'cmdb': cmdb/migrations/0003_alladdress_device.py - Create model alladdress - Create model device Process finished with exit code 0 {{{ manage.py@dev > migrate ssh://root@10.32.109.197:22/proj/env/bin/python3 -u /root/.pycharm_helpers/pycharm/django_manage.py migrate /proj/app/mysite File tracking disabled Operations to perform: Apply all migrations: admin, auth, cmdb, contenttypes, sessions Running migrations: Applying cmdb.0001_initial...Traceback (most recent call last): File "/root/.pycharm_helpers/pycharm/django_manage.py", line 59, in <module> run_command() File "/root/.pycharm_helpers/pycharm/django_manage.py", line 46, in run_command run_module(manage_file, None, '__main__', True) File "/usr/local/python3/lib/python3.8/runpy.py", line 207, in run_module return _run_module_code(code, init_globals, run_name, mod_spec) File "/usr/local/python3/lib/python3.8/runpy.py", line 97, in _run_module_code _run_code(code, mod_globals, init_globals, File "/usr/local/python3/lib/python3.8/runpy.py", line 87, in _run_code exec(code, run_globals) File "/proj/app/mysite/manage.py", line 22, in <module> main() File "/proj/app/mysite/manage.py", line 18, in main execute_from_command_line(sys.argv) File "/proj/env/lib/python3.8/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line utility.execute() File "/proj/env/lib/python3.8/site-packages/django/core/management/__init__.py", line 395, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/proj/env/lib/python3.8/site-packages/django/core/management/base.py", line 330, in run_from_argv self.execute(*args, **cmd_options) File "/proj/env/lib/python3.8/site-packages/django/core/management/base.py", line 371, in exe… nobody 315xiaoyao operations.py, AttributeError: 'tuple' object has no attribute 'startswith' 0 0 0 0 0 1
32025 2020-09-21 15:15:06 2020-09-21 16:15:13 2022-03-06 04:58:07.362934 Unreviewed closed Error reporting Bug Release blocker 3.1 duplicate AttributeError: 'tuple' object has no attribute 'startswith' manage.py@dev > migrate ssh://root@10.32.109.197:22/proj/env/bin/python3 -u /root/.pycharm_helpers/pycharm/django_manage.py migrate /proj/app/mysite File tracking disabled Operations to perform: Apply all migrations: admin, auth, cmdb, contenttypes, sessions Running migrations: Applying cmdb.0001_initial...Traceback (most recent call last): File "/root/.pycharm_helpers/pycharm/django_manage.py", line 59, in <module> run_command() File "/root/.pycharm_helpers/pycharm/django_manage.py", line 46, in run_command run_module(manage_file, None, '__main__', True) File "/usr/local/python3/lib/python3.8/runpy.py", line 207, in run_module return _run_module_code(code, init_globals, run_name, mod_spec) File "/usr/local/python3/lib/python3.8/runpy.py", line 97, in _run_module_code _run_code(code, mod_globals, init_globals, File "/usr/local/python3/lib/python3.8/runpy.py", line 87, in _run_code exec(code, run_globals) File "/proj/app/mysite/manage.py", line 22, in <module> main() File "/proj/app/mysite/manage.py", line 18, in main execute_from_command_line(sys.argv) File "/proj/env/lib/python3.8/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line utility.execute() File "/proj/env/lib/python3.8/site-packages/django/core/management/__init__.py", line 395, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/proj/env/lib/python3.8/site-packages/django/core/management/base.py", line 330, in run_from_argv self.execute(*args, **cmd_options) File "/proj/env/lib/python3.8/site-packages/django/core/management/base.py", line 371, in execute output = self.handle(*args, **options) File "/proj/env/lib/python3.8/site-packages/django/core/management/base.py", line 85, in wrapped res = handle_func(*args, **kwargs) File "/proj/env/lib/python3.8/site-packages/django/core/management/commands/migrate.py", line 243, in handle post_migrate_state = executor.migrate( File "/pro…   315xiaoyao operations.py, AttributeError: 'tuple' object has no attribute 'startswith' 0 0 0 0 0 1
32026 2020-09-21 15:17:57 2020-09-21 16:15:25 2022-03-06 04:58:07.514119 Unreviewed closed Error reporting Bug Release blocker 3.1 duplicate AttributeError: 'tuple' object has no attribute 'startswith' manage.py@dev > migrate ssh://root@10.32.109.197:22/proj/env/bin/python3 -u /root/.pycharm_helpers/pycharm/django_manage.py migrate /proj/app/mysite File tracking disabled Operations to perform: Apply all migrations: admin, auth, cmdb, contenttypes, sessions Running migrations: Applying cmdb.0001_initial...Traceback (most recent call last): File "/root/.pycharm_helpers/pycharm/django_manage.py", line 59, in <module> run_command() File "/root/.pycharm_helpers/pycharm/django_manage.py", line 46, in run_command run_module(manage_file, None, '__main__', True) File "/usr/local/python3/lib/python3.8/runpy.py", line 207, in run_module return _run_module_code(code, init_globals, run_name, mod_spec) File "/usr/local/python3/lib/python3.8/runpy.py", line 97, in _run_module_code _run_code(code, mod_globals, init_globals, File "/usr/local/python3/lib/python3.8/runpy.py", line 87, in _run_code exec(code, run_globals) File "/proj/app/mysite/manage.py", line 22, in <module> main() File "/proj/app/mysite/manage.py", line 18, in main execute_from_command_line(sys.argv) File "/proj/env/lib/python3.8/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line utility.execute() File "/proj/env/lib/python3.8/site-packages/django/core/management/__init__.py", line 395, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/proj/env/lib/python3.8/site-packages/django/core/management/base.py", line 330, in run_from_argv self.execute(*args, **cmd_options) File "/proj/env/lib/python3.8/site-packages/django/core/management/base.py", line 371, in execute output = self.handle(*args, **options) File "/proj/env/lib/python3.8/site-packages/django/core/management/base.py", line 85, in wrapped res = handle_func(*args, **kwargs) File "/proj/env/lib/python3.8/site-packages/django/core/management/commands/migrate.py", line 243, in handle post_migrate_state = executor.migrate( File "/p…   315xiaoyao AttributeError: 'tuple' object has no attribute 'startswith' 0 0 0 0 0 1
24911 2015-06-03 23:09:38 2015-06-30 17:54:11 2022-03-06 04:38:59.855647 Accepted closed Database layer (models, ORM) Bug Normal 1.8 fixed QuerySet is initiated with model=None as kwarg, but is called in BaseManager.get_queryset() as arg. QuerySet is initiated with {{{model=None}}} as named argument a.k.a. kwarg: {{{ class QuerySet(object): def __init__(self, model=None, query=None, using=None, hints=None): }}} But it is called in {{{get_queryset()}}} as positional argument a.k.a. arg: {{{ def get_queryset(self): return self._queryset_class(self.model, using=self._db, hints=self._hints) }}} This causes trouble when overriding {{{get_queryset}}} (which is the idea behind the method) and using {{{super(BlaBlaManager, self).get_queryset()}}} which returns a non-standard queryset-class, where model is not necessarily the first argument, which should have been okay as model is a named argument. Proposed solution: in db/models/manager.py {{{ def get_queryset(self): return self._queryset_class(model=self.model, using=self._db, hints=self._hints) }}} Github pull request: https://github.com/django/django/pull/4745 317070 317070   1 1 0 0 0 0
19193 2012-10-26 17:39:02 2015-10-08 23:41:31 2022-03-06 04:10:38.529710 Accepted closed Database layer (models, ORM) New feature Normal dev duplicate Save only one field to database which refereced to FieldFile `django.db.models.fields.FieldFile`: {{{ def save(self, name, content, save=True): .... if save: self.instance.save(update_fields=[self.field.name]) .... }}} or: {{{ def save(self, name, content, save=True, **kwargs) .... if save: self.instance.save(**kwargs) .... }}} So, we get rid of re-saving fields when updating nobody 3dflex@gmail.com   0 0 0 0 0 0
11179 2009-05-22 12:53:56 2009-08-08 20:40:56 2022-03-06 03:49:18.516455 Unreviewed closed django-admin.py inspectdb     1.0 wontfix inspectdb should guess related_name on foreign keys It would be useful if inspectdb would guess related_name parameter on foreign keys using db_table, db_column and othermodel attributes. >> Accessor for field 'xxx' clashes with related field 'YYY.zzz_set'. Add a related_name argument to the definition for 'xxx'. >> Accessor for field 'aaa' clashes with related field 'YYY.zzz_set'. Add a related_name argument to the definition for 'aaa'. Thnx nobody 3gun related_name 0 0 0 0 0 0
12460 2009-12-29 14:18:11 2012-08-23 19:47:35 2022-03-06 03:52:37.077390 Accepted closed Core (Management commands) Bug Normal dev fixed inspectdb and field names ending with underscores Hi, There is a field named 'type_' in mysql table. Inspectdb inspects it as 'type_' and model does not validate. I suggest removing underscores from model field name and specifying column_db argument in field constructor. < type_ = models.CharField(max_length=90, db_column='type_') > type = models.CharField(max_length=90, db_column='type_') Sorry for posting without login. I've forgot my password and didn't find restoring feature on this site. kgibula 3gun <mihail.lukin@googlemail.com> inspectdb underscore characters digits 0 1 0 0 0 0
13459 2010-05-02 11:53:36 2011-09-28 16:12:23 2022-03-06 03:55:15.658289 Accepted closed contrib.admin     dev fixed nonzero extra inlines and "add another" create duplicate <tr> ids The first new row of an admin inline created by the "add another" button has the same id as the immediately preceding "extra" row. An admin model that contains an inline with the "extra" option set to a non zero value creates <tr>s with id suffixes starting from 1. When the !JavaScript "add another" function is called, it creates id suffixes assuming that the first row id was numbered 0. This may have been a side effect of fixing #13175. Using forloop.counter0 in the inline templates when generating the extra inlines solves the problem. nobody 3point2   0 1 0 0 0 0
13679 2010-06-01 23:29:29 2011-09-28 16:12:27 2022-03-06 03:55:51.697101 Accepted closed Forms     1.2 fixed ModelForms (and hence the admin) no longer honor the default value for a ForeignKey In Django 1.1, it was possible to use a callable to set the default value on a !ForeignKey field. This functionality was broken in r12721 and doesn't currently work in Django 1.2. Example: {{{ def get_default(): return SomeModel.objects.get(id=5) class Test(models.Model): foo = models.ForeignKey(SomeModel, default=get_default) }}} This model should display in the admin with the default !SomeModel already selected in the drop-down box. The !ModelForm code that does this seems to have been confused by the changes made in r12721. The code in the Field class in django/db/models/fields/!__init!__.py could also do with a cleanup: formfield() first checks has_default() before calling get_default(), which also checks has_default(). The patch in r12721 adds to this duplication of logic by checking if self.default is callable, which is also done by get_default(). nobody 3point2   0 0 0 0 0 0
13950 2010-07-16 02:32:14 2012-03-25 21:01:24 2022-03-06 03:56:36.461400 Unreviewed closed contrib.admin Uncategorized Normal 1.2 wontfix Add "post save" hook to ModelAdmin class If a model with a set of related objects is edited in the admin, there is currently no way to run any code once the admin site has saved the related objects. For example, consider an invoice: models.py: {{{ class Invoice(models.Model): # fields like customer_name, etc total = models.DecimalField(max_digits=11, decimal_places=2) def update_total(self): self.total = sum([x.cost for x in self.invoiceentry_set.all()] class InvoiceEntry(models.Model): invoice = models.ForeignKey(Invoice) item = models.CharField(max_length=100) cost = models.DecimalField(max_digits=11, decimal_places=2) # etc }}} When clicking "save" in the admin after editing or adding an invoice in the admin interface, there is no way to have the invoice update its total using the update_total method. Overriding the save() method on the Invoice model doesn't help, because it is called before the related !InvoiceEntries are created and saved. I supposes the functionality I want could be implemented by overriding the save() method for the !InvoiceEntry model and have it update the total of the parent instance, although this seems a little inelegant as the Invoice instance would then be updated and saved once for every invoice entry created or edited. I suggest adding a "post_save" option to the !ModelAdmin class, which will be called once all related objects have been saved. Please consider the attached patch. It allows the following: admin.py: {{{ class InvoiceAdmin(admin.ModelAdmin): def post_save(self, instance): instance.update_total() admin.site.register(Invoice, InvoiceAdmin) }}} With the patch, the post_save method above is called after the invoice and all its related entries have been created and saved. If this is considered for inclusion into Django, I'd be happy to modify the patch to include documentation. Vasili pandres 3point2   0 1 1 1 1 0
14038 2010-07-31 00:24:17 2011-01-25 15:44:42 2022-03-06 03:56:49.293512 Accepted closed Documentation     1.2 fixed 1.2 Release notes don't mention new template loader classes As of 1.2, template loaders like django.template.loaders.filesystem.load_template_source have been deprecated in favor of django.template.loaders.filesystem.Loader. This is not mentioned in the release notes, but other deprecated settings (like DATABASE_*) are. nobody 3point2   0 0 0 0 1 0
14172 2010-08-26 11:00:09 2010-08-26 11:10:46 2022-03-06 03:57:12.098617 Unreviewed closed Documentation     1.2 fixed small typo in admin action docs this is a little nit-picky i know, but 'explicitally' under "disabling a site-wide action' should be 'explicitly' (http://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/#django.contrib.admin.AdminSite.disable_action) nobody 3point2   0 0 0 0 0 0
15536 2011-03-03 00:18:00 2013-04-19 03:56:25 2022-03-06 04:00:48.152480 Accepted closed Forms Uncategorized Normal 1.4 invalid ModelForm validation regression in 1.2 when using TimeField with choices This is my test case models.py: {{{ from django.db import models from django import forms TIME_CHOICES = ( ("09:00:00", "9 AM"), ("17:00:00", "5 PM") ) class TestModel(models.Model): time = models.TimeField(choices=TIME_CHOICES) class TestForm(forms.ModelForm): class Meta: model = TestModel }}} This is what happens with Django 1.1.4: {{{ >>> f = TestForm({"time": "09:00:00"}) >>> f.errors {} }}} and this is what happens with Django 1.2.5: {{{ >>> f = TestForm({"time": "09:00:00"}) >>> f.errors {'time': [u'Value datetime.time(9, 0) is not a valid choice.']} }}} It looks like in 1.2 the supplied time is being converted into a datetime instance before being compared to the valid choices. It would be great to see this incompatible change from 1.1 fixed or documented. nobody 3point2 blocker, regression 0 0 0 0 0 0
17984 2012-03-26 15:08:24 2013-03-23 10:21:48 2022-03-06 04:07:20.835016 Design decision needed closed contrib.admin Bug Normal 1.4 wontfix admin list_filter security fix doesn't allow 'pk' lookups in query string Let's say I have a Payment model containing a received_by field that is a !ForeignKey to a Customer model. Now I add this to my Payment !ModelAdmin: {{{ list_filter = ["received_by"] }}} If I use a query string like "?received_by!__id!__exact=2" on the payment changelist view, there is no problem. This is the form that the admin itself uses for the filter. Using something more implicit like "?received_by!__id=2" works fine too. However, using "?received_by!__pk=2" raises !SuspiciousOperation. This was introduced by the security fix in r15031. The lookup_allowed method in admin/options.py explicitly makes an exception for "!__id" (or whatever the primary key attribute of the model is explicitly called), but it doesn't allow direct use of the 'pk' shortcut. The point of the security fix was to only allow lookups specified by list_filter. However, in its current form it also causes the query string syntax to diverge from the documented lookup syntax https://docs.djangoproject.com/en/1.4/topics/db/queries/#the-pk-lookup-shortcut . I suggest allowing use of the pk shortcut in the query string. I would be happy to write a patch for this if the developers agree it should be fixed. nobody 3point2   0 0 0 0 0 0
17985 2012-03-26 15:16:24 2017-09-02 18:10:06 2022-03-06 04:07:20.986801 Accepted closed Documentation New feature Normal 1.4 fixed Document ModelAdmin.lookup_allowed() Right now, as a result of the security fix introduced in r15031, the only way to allow querystring lookups across relationships in the admin is to whitelist them by including them in list_filter. However, in my application the lookup that needs to be whitelisted generates a huge filter widget as it contains thousands of instances. It would be helpful if I could whitelist the exact lookup I need to link to without having to generate the filter widget itself. Something like {{{ class MyModelAdmin(ModelAdmin): allow_lookup = ["fieldname__id__exact"] }}} would do. If the developers agree this is useful functionality, I could write a patch. DrMeers 3point2   0 1 0 0 0 0
23704 2014-10-22 19:54:31 2014-10-23 18:57:55 2022-03-06 04:24:45.507149 Unreviewed closed Uncategorized Bug Normal 1.7 invalid Error in manage.py runserver on Windows (7 / 8 / 8.1) I've added the 3 versions mentioned in the summary because while searching for a solution to this bug I've found that it occurred in those ones also. == Technical Specs == System: Windows 8.1 Python: 3.4 Django: 1.7 Virtual Enviroment: 2.7 == Explanation of the bug == After creating my project with "manage.py startproject" I tried to check if it was created correctly by running the local server. When I tried to do so with "manage.py runserver" a command feedback appeared reporting the next error: [[Image(http://s21.postimg.org/e362aaql3/traceback_error.png)]] In line 279, the code indicated that it was a problem with the encoding of a character. For what I know 'mbcs' codec is only used with Windows machines. I tried all suggestions in StackOverflow and the likes with no improvement. Then I started digging in the code and I found the file with the error "autoreload.py": [[Image(http://s21.postimg.org/5v44payon/autoreload_before.png)]] The problem occurred with the method "os.spawnve" that executes the program path in a new process. The real usage is beyond my knowledge. I decided to look up the arguments that were given to this function and printed each one of them to see what was happening. The arguments "sys.executable" & "args" didn't present any errors. It was a clean print. "new_environ", that's another story. It presented a new error indicating that a Unicode value (\u202a) couldn't be decoded by the function charmap. I searched this particular Unicode and it's used for indicating '''directional embedding''' (more of this at: [http://unicode.org/reports/tr9/#Directional_Formatting_Codes]). It appears that this particular Unicode character isn't supported in Windows, that includes the 3 versions indicated in the summary. It so strange to Windows environment that even if you try to search the code in a browser it can't recognized it: [[Image(http://s21.postimg.org/ucw8d7193/path_key.png)]] After that I tried to print each key with … nobody 3rdWorldCitizen Windows runserver 0 0 0 0 0 0
30104 2019-01-15 10:14:39 2019-01-15 15:51:09 2022-03-06 04:53:03.110901 Unreviewed closed Database layer (models, ORM) Uncategorized Normal 2.1 invalid Need filtering by Window expression I use Row_Number function with WIndow expression. And i need to filter only second rows. {{{ History.objects.annotate(row=Window(expression=RowNumber(), partition_by=[F('ad_id')], order_by=F('updated_at').desc())).filter(row=2) }}} But this exception raised: {{{ django.db.utils.NotSupportedError: Window is disallowed in the filter clause. }}} Why Window is disallowed in the filter clause? Is there other way to do this? nobody 3wade3 orm, window, row_number, filter 1 0 0 0 0 0
24250 2015-01-30 10:22:57 2015-02-03 14:10:30 2022-03-06 04:27:03.817012 Ready for checkin closed Documentation Bug Normal 1.7 fixed Class FormMixin does not provide "form" variable in centext. Class FormMixin does not provide "form" variable in centext. Documentation states that it should https://docs.djangoproject.com/en/1.7/ref/class-based-views/mixins-editing/#formmixin nobody 4544fa8d FormMixin form context 0 1 0 0 0 0
23715 2014-10-26 07:48:09 2014-10-31 12:07:44 2022-03-06 04:24:47.085853 Ready for checkin closed Template system Bug Normal 1.7 fixed Template tag urlize and exclamation mark The template tag `urlize` cannot create the urls correctly when an exclamation mark follows an url. text = "Check out www.djangoproject.com!" text|urlize results in: "Check out <a href="(...)!">www.djangoproject.com!</a>" MarkusH 57even   0 1 0 0 0 0
20217 2013-04-08 08:26:24 2013-04-08 22:56:01 2022-03-06 04:13:20.848013 Unreviewed closed Database layer (models, ORM) Bug Normal 1.3 invalid query model using `filter` or `get` occur ValueError: invalid literal for int() with base 10 class User(models.Model): identifier=models.CharField(max_length=128, unique=True, db_index=True) .......... .......... class Token(models.Model): user = models.ForeignKey("User", related_name="Tokens") token_string = models.CharField(max_length=128, unique=True, db_index=True) while I already have a tk(<Token object>),I run this: user = User.objects.filter(id=tk.user_id) if user: user = user[0] it cause the ValueError: invalid literal for int() with base 10: File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 113, in __nonzero__ iter(self).next() File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 107, in _result_iter self._fill_cache() File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 772, in _fill_cache self._result_cache.append(self._iter.next()) File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 273, in iterator for row in compiler.results_iter(): File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 680, in results_iter for rows in self.execute_sql(MULTI): File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 735, in execute_sql cursor.execute(sql, params) File "/usr/local/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 86, in execute return self.cursor.execute(query, args) File "build/bdist.linux-x86_64/egg/MySQLdb/cursors.py", line 174, in execute self.errorhandler(self, exc, value) File "build/bdist.linux-x86_64/egg/MySQLdb/connections.py", line 36, in defaulterrorhandler raise errorclass, errorvalue ValueError: invalid literal for int() with base 10: '\xd9' but it disappeared when I restart my project, but a couple of days while running, it occured again How does it happened and any solutions? nobody 592280502@qq.com   0 0 0 0 0 0
20225 2013-04-09 01:47:11 2013-04-09 01:52:53 2022-03-06 04:13:21.923310 Unreviewed closed *.djangoproject.com Bug Normal 1.3 needsinfo query model using `filter` or `get` occur ValueError: invalid literal for int() with base 10 class User(models.Model): identifier=models.CharField(max_length=128, unique=True, db_index=True) .......... .......... class Token(models.Model): user = models.ForeignKey("User", related_name="Tokens") token_string = models.CharField(max_length=128, unique=True, db_index=True) while I already have a tk(<Token object>),I run this: user = User.objects.filter(id=tk.user_id) if user: user = user[0] it cause the ValueError: invalid literal for int() with base 10: File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 113, in nonzero iter(self).next() File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 107, in _result_iter self._fill_cache() File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 772, in _fill_cache self._result_cache.append(self._iter.next()) File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 273, in iterator for row in compiler.results_iter(): File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 680, in results_iter for rows in self.execute_sql(MULTI): File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 735, in execute_sql cursor.execute(sql, params) File "/usr/local/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 86, in execute return self.cursor.execute(query, args) File "build/bdist.linux-x86_64/egg/MySQLdb/cursors.py", line 174, in execute self.errorhandler(self, exc, value) File "build/bdist.linux-x86_64/egg/MySQLdb/connections.py", line 36, in defaulterrorhandler raise errorclass, errorvalue ValueError: invalid literal for int() with base 10: '\xd9' but it disappeared when I restart my project, but a couple of days while running, it occured again How does it happened and any solutions? nobody 592280502@qq.com ValueError 0 0 0 0 0 0
26414 2016-03-27 16:57:05 2016-03-27 17:12:02 2022-03-06 04:43:50.119667 Unreviewed closed contrib.postgres Bug Normal 1.9 duplicate postgres_test fail with psycopg2==2.4.5 {{{#!bash $ pip freeze |grep psycopg2 psycopg2==2.4.5 $ PYTHONPATH=..:$PYTHONPATH ./runtests.py postgres_tests Traceback (most recent call last): File "./runtests.py", line 458, in <module> options.debug_sql, options.parallel) File "./runtests.py", line 275, in django_tests extra_tests=extra_tests, File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/test/runner.py", line 532, in run_tests old_config = self.setup_databases() File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/test/runner.py", line 482, in setup_databases self.parallel, **kwargs File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/test/runner.py", line 726, in setup_databases serialize=connection.settings_dict.get("TEST", {}).get("SERIALIZE", True), File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/db/backends/base/creation.py", line 78, in create_test_db self.connection._test_serialized_contents = self.serialize_db_to_string() File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/db/backends/base/creation.py", line 122, in serialize_db_to_string serializers.serialize("json", get_objects(), indent=None, stream=out) File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/core/serializers/__init__.py", line 129, in serialize s.serialize(queryset, **options) File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/core/serializers/base.py", line 79, in serialize for count, obj in enumerate(queryset, start=1): File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/db/backends/base/creation.py", line 118, in get_objects for obj in queryset.iterator(): File "/home/user/dev/env/django-1…   612d7368   0 1 0 0 0 0
21408 2013-11-08 21:22:05 2018-09-29 13:07:45 2022-03-06 04:16:24.518362 Ready for checkin closed Internationalization Bug Normal dev fixed Fallback to timesince produces erroneous translations in naturaltime The [[https://docs.djangoproject.com/en/dev/ref/contrib/humanize/#naturaltime|naturaltime]] filter in `django.contrib.humanize` composes strings for days, weeks, months, and years from the words "ago" and "in" and the output of the built-in [[https://docs.djangoproject.com/en/dev/ref/templates/builtins/#timesince|timesince]] filter. See here, where `delta` is to be supplied by `timesince`: {{{ #: templatetags/humanize.py:190 #, python-format msgctxt "naturaltime" msgid "%(delta)s ago" msgstr "vor %(delta)s" }}} This produces erroneous translations in German (and probably other inflectional languages, too). "3 days, 12 hours ago" is translated by Django as {{{ vor 3 Tage, 12 Stunden }}} but the correct translation is (with dative inflection) {{{ vor 3 Tagen, 12 Stunden }}} "3 Tage" is correct for `timesince`, but for `naturaltime` it must become "3 Tagen". Unfortunately, the assumption that these translations can simply be pieced together from translated bits in timesince.py is mistaken. I apologise if this isn't the right channel. I'd be glad to help, but so far I haven't seen a good way to avoid duplicating translations. mxmerz 676c7473@gmail.com i18n l10n translation 0 1 0 0 0 0
21415 2013-11-09 18:15:52 2017-07-05 06:41:48 2022-03-06 04:16:25.779905 Accepted closed Translations Bug Release blocker 1.6 fixed Unicode escapes appear verbatim in translated naturaltime strings In Django 1.6, the Unicode escape `\u00a0` "non-breaking space" that was introduced in the translations is doubly-escaped and now appears verbatim in the output of `django.contrib.humanize.naturaltime`. What used to be {{{ vor 6 Sekunden }}} that is the German ("de") translation for "6 seconds ago", now appears as {{{ vor 6\u00a0Sekunden }}} in templates that use `naturaltime`. This affects all `django/contrib/humanize/locale/<language>/LC_MESSAGES/django.po` files. Not sure if this should be treated as a translation bug, and how? claudep 676c7473@gmail.com i18n l10n translation 0 1 0 0 0 0
17859 2012-03-09 03:02:55 2012-03-09 03:32:32 2022-03-06 04:07:00.028727 Unreviewed closed Uncategorized Uncategorized Normal 1.3 needsinfo Undefined variable from import: cursor 1def graph_templates(host_id): 2from django.db import connection 3 cursor=connection.cursor() It marked an error at line 3 :Undefined variable from import: cursor nobody 775725322@qq.com Undefined variable from import cursor 0 0 0 0 0 0
8838 2008-09-03 11:07:42 2011-09-28 16:12:17 2022-03-06 03:43:17.923173 Ready for checkin closed Documentation     dev fixed typo in model fields docs http://docs.djangoproject.com/en/dev/ref/models/fields/#positivesmallintegerfield PositiveSmallIntegerField -class PositiveIntegerField([**options]) +class PositiveSmallIntegerField([**options]) nobody 7times9 typo model fields docs 0 1 0 0 0 0
8839 2008-09-03 11:13:06 2011-09-28 16:12:17 2022-03-06 03:43:18.074916 Unreviewed closed Documentation     dev duplicate typo in model fields docs http://docs.djangoproject.com/en/dev/ref/models/fields/#imagefield -class ImageField(upload_to-None[, height_field=None, width_field=None, max_length=100, **options]) +class ImageField(upload_to=None[, height_field=None, width_field=None, max_length=100, **options]) ^ nobody 7times9 typo model fields docs 0 1 0 0 0 0
14188 2010-08-28 23:59:08 2010-08-29 00:29:54 2022-03-06 03:57:14.813877 Unreviewed closed Documentation     dev duplicate permalink docs import mistake The first example has: {{{ from django.db import models @models.permalink def get_absolute_url(self): }}} which is fine. But {{{ from django.db.models import permalink @models.permalink def get_absolute_url(self): }}} won't work. Patch makes consistent with first example. nobody 7times9 import 0 1 0 0 0 0
14189 2010-08-29 00:07:24 2010-08-30 10:31:56 2022-03-06 03:57:14.978178 Ready for checkin closed Documentation     dev fixed permalink docs import mistake The first example has: {{{ from django.db import models @models.permalink def get_absolute_url(self): }}} which is fine. But {{{ from django.db.models import permalink @models.permalink def get_absolute_url(self): }}} won't work. Patch makes consistent with first example. nobody 7times9 import 0 1 0 0 0 0
33382 2021-12-23 03:44:35 2021-12-24 03:08:09 2022-03-06 05:01:31.165603 Unreviewed closed Database layer (models, ORM) Uncategorized Normal 3.2 duplicate Different count and len result for a distinct QuerySet The problem arises when I use the len method on a distinct queryset. The object obtained by the len method seems to be not distinct , But the query did not change during this time. I found what looks like the same Ticket ，But I'm not sure it's the same reason [https://code.djangoproject.com/ticket/30655] Here is a simple example that shows the contrary. Models: {{{ class Exam(models.Model): paper = models.ForeignKey(ExamPaper, related_name='paper_exam', on_delete=models.CASCADE, blank=True, null=True) class StudentPaper(models.Model): user = models.ForeignKey(User, related_name='user_exam_paper', on_delete=models.CASCADE) exam = models.ForeignKey(Exam, related_name='exam_student_paper', on_delete=models.CASCADE) }}} Shell Output: {{{ >>> from ExamManage.models import* >>> exam = Exam.objects.first() >>> exam.exam_student_paper.filter(is_pass=True).values('user_id').count() 521 >>> support_pass_userids = exam.exam_student_paper.filter(is_pass=True).values('user_id').distinct() >>> support_pass_userids.count() 484 >>> print(support_pass_userids.query) SELECT DISTINCT `ExamManage_studentpaper`.`user_id`, `ExamManage_studentpaper`.`id` FROM `ExamManage_studentpaper` WHERE (`ExamManage_studentpaper`.`exam_id` = 5 AND `ExamManage_studentpaper`.`is_pass`) ORDER BY `ExamManage_studentpaper`.`id` DESC >>> len(support_pass_userids) 521 >>> support_pass_userids.count() 521 >>> print(support_pass_userids.query) SELECT DISTINCT `ExamManage_studentpaper`.`user_id`, `ExamManage_studentpaper`.`id` FROM `ExamManage_studentpaper` WHERE (`ExamManage_studentpaper`.`exam_id` = 5 AND `ExamManage_studentpaper`.`is_pass`) ORDER BY `ExamManage_studentpaper`.`id` DESC }}} nobody 826541814   0 0 0 0 0 0

Next page

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE tickets (
        id int primary key,
        created datetime,
        changetime datetime,
        last_pulled_from_trac datetime,
        stage text,
        status text,
        component text,
        type text,
        severity text,
        version text,
        resolution text,
        summary text,
        description text,
        owner text,
        reporter text,
        keywords text,
        easy boolean,
        has_patch boolean,
        needs_better_patch boolean,
        needs_tests boolean,
        needs_docs boolean,
        ui_ux boolean
    );