I've run into a bug that is exposed when using defer() or only() with
select_related(). A couple others have come across it, and there is an
existing ticket.
Exceptions appear to be silenced somewhere under normal circumstances
when evaluating `queryset` objects, which made it difficult to track
d
The easy way (and what I do now) is create your "skel" folder in SVN
(or whatever you use), then just do an svn copy for new projects and
away you go. That way you can also store common svn:externals or
svn:ignore properties in your directory structure as well.
On May 29, 12:12 am, phillc <[EMAI
Personally I loosely follow trunk so I'm not waiting for 1.0, and I
don't really care how many "releases" there are between now and 1.0.
What I would like to see is the last few major NFA blockers fixed and
NFA merged into trunk. Just get it out there in trunk, so we can get
more real world use re
There are a few open tickets that I'm aware of (4412, 4604) which are
either ready for checkin or are waiting for NFA to hit trunk before
moving to ready for checkin. The work is done (patch, docs, tests).
Should these be included in the 1.0-beta or 1.0 milestone?
--~--~-~--~~---
I've implemented some code already to de-reference (SET_NULL) on
delete, in a view which first presents a list of objects which will be
deleted and a list of objects which will be de-referenced. It might
not be the most efficient approach, but it could be a starting point.
def _clear(instance):
I like it. I've run into a few cases recently where I just needed a
simple_tag with access to the context.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
http://code.djangoproject.com/ticket/7581
Just posted this ticket with an initial patch (sans documentation
changes and tests). Basically there are several middleware classes
that access HttpResponse.content directly which break streaming
HttpResponse objects that use a generator to yield content
Certainly the implementation of the patch is not ideal (by accessing
private attributes on HttpResponse), which is why I brought it up for
discussion before going any further.
I do feel that there is a real benefit and even requirement in some
cases to supporting streaming HttpResponse objects. I
On Jul 1, 7:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> It's quite a large restriction to say that no middleware should ever try
> to examine the contents of the HttpResponse since it might be an
> iterator that shouldn't be consumed. You're proposing a bunch of
> specific changes for
> The only thing that might be worth doing in this are is adding a way to
> say "middleware should never be called on this response" and then
> somebody can write their own HttpResponse subclass and be in complete
> control of their destiny.
Would this disable ALL middleware from running? Or only
1.0 should ideally ship with Zarro Boogs, so any bugs (not DDN)
especially trivial ones with a patch including relavent tests / docs
should be marked for 1.0 milestone, I think ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Go
Even better, make the entire row the link (like trac). I don't see why
only the value of the first field should be the link.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
Isn't click to focus a window (or not) an OS decision? E.g. clicking
anywhere in a browser window on a Mac will focus the window but not
send a click to the application.
Even if that weren't the case, making the link area smaller just
reduces the probability for accidental clicks and makes it mor
> If I'm not mistaken, in NFA, you can create a custom subclass of
> ModelAdmin that always sets list_display_links equal to list_display,
> and have all of your models inherit from that. This is the most
> flexible solution because people who don't want it to default to
> clickable get their way
A documentation change about using a different field type is not
enough in some cases (PostgreSQL 8.3), as noted in #6523 [1].
PostgreSQL 8.3 won't implicitly cast variables anymore, so if you pick
integer for your generic relation you'll have problems relating models
with varchar, and vice versa.
http://code.djangoproject.com/ticket/8149
As mentioned in the ticket, `UploadedFile.__iter__` iterates over a
`StringIO` object to yield each line of the uploaded file (including
line endings). Unfortunately the current version of `StringIO` only
treats `\n` as a line ending, but iterating over a
In your hypothetical, how would you handle boolean fields with a
checkbox widget? When they are unticked, they are not included in the
QueryDict. It could get confusing if we start special casing fields
like these in order to support "no data" as a different case to "empty
data", just to avoid hav
On a few occasions I've found myself doing something like:
instance, created =
Model.objects.get_or_create(something=something, ..., defaults={
'somethingelse': somethingelse,
...
})
if not created:
instance. somethingelse = somethingelse
...
instance.save()
I'd like to propo
I've just had another thought. With `SplitDateTimeWidget` validation
coupled to `DateTimeField`, it's no longer easy to subclass
`DateTimeField` for use with your own `MultiValueWidget`. When you
call `super` for the DateTimeField validation, it will run
`DateTimeField.clean` which will return an
On Sep 23, 3:54 am, mrts <[EMAIL PROTECTED]> wrote:
> +1 for adding a way to say "process_response should never be called on
> this response".
>
> Taking a quick look at the source, HttpResponse seems to support
> iteration already:
>
> def __iter__(self):
> self._iterator = iter(self.
On Sep 23, 9:27 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> The significant downside is that having a render() method on a form
> that performs the same function as render_to_response feels really,
> really strange. It's convenient, but it just doesn't feel right and
> I'm not sure I can justi
In #8149 [1] I reported that `UploadedFile` uses `StringIO` to iterate
through uploaded files line-by-line, but `StringIO` only treats `\n`
as a line ending, at least in the current version.
This effectively means we can't use line-by-line iteration over
uploaded files because we don't know what
#8898 is a simple bug fix with tests for DateTime fields with
required=False, which currently fail to validate in the admin because
the `required` validation is being bypassed when using
SplitDateTimeWidget with DateTimeField (which seems questionable to
begin with).
I'd set it to ready for check
I'd love to see this feature implemented. I was previously
(mistakenly) using `management.py` in my app folders for this,
thinking that it was imported when any management command was executed
(such as `runfcgi`, `runserver`, `shell`, etc). Unfortunately it's
only imported when `syncdb` is execute
If it feels wrong to put a command in "project/app1", you can put it
in "project" and simply add "project" to your INSTALLED_APPS. You can
then place any models, management commands, URLs, views, or anything
else that is common to all your "apps" in the "project" app.
--~--~-~--~~---
On Nov 1, 1:38 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
>
> Really, there is not reluctance to get input on what should be fixed before
> 1.0.1 is released. It's just that input in the form of working patches with
> tests and doc is far more valuable than a simple bit on a ticket. The list
Thanks for your feedback, Karen.
> http://code.djangoproject.com/ticket/8898
>
> I suspect this one may be stalled because it is in design decision needed
> state with a last comment that makes it sound like the existing patch (added
> before the last comment) is not correct and that the right fi
On Nov 2, 10:57 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
>
> You do know that Karen has a commit bit, right? If she's got concerns
> about a ticket, then I at least take that as meaning it's got problems
> and isn't ready for checkin.
Yes, I did notice that. However, as I said, there is sti
I currently use my own versions of `send_mail` and `mail_*`, which
hijack the recipients if DEBUG is True. The idea being that I don't
want to send real emails to real recipients while developing,
debugging and testing.
In this case I get real emails delivered to everyone listed in
`settings.ADMI
Specifically, in `django.contrib.sessions.tests`:
> ..F.
> ==
> FAIL: Doctest: django.contrib.sessions.tests
> --
> Traceback (most recent call last)
I've used and would like to see at least JSONField and/or PickleField
in contrib/core. Here's a link to my current implementation.
http://dpaste.com/hold/100270/
If it's not going to make it into contrib/core, I'd welcome any
suggestions, improvements or alternative implementations.
Cheers.
Tai
I'd also love to see 8898 committed. It looks to be a fairly straight-
forward bug fix, at least to me.
http://code.djangoproject.com/ticket/8898
Cheers.
Tai.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
I'd like to bring attention to several tickets that have been sitting
unreviewed for 3-5 months. Most are fairly trivial fixes for bugs and
inconsistencies. Most have a patch and/or tests. I believe that all
are backwards compatible. I'd really appreciate feedback from any core
developers, or anot
One of the desired but lacking a champion features for 1.1 ([ORM-09],
#3182) has been updated to work with r9844 with tests and docs, and
improved as per the last comments on the ticket.
I think this one is ready to go in, but I didn't want to set the
ticket "ready for checkin" until someone else
In my bike shed (and cron's), Sunday is 0 AND 7, which seems nice.
Then your week can starting with Sunday as 0-6 or Monday as 1-7.
Oh, I see that Bob Thomas already suggested this. Isn't it a moot
point, though? Isn't it considered a backwards incompatible change
even if made before 1.1? Or is
> I'm very unconvinced that the idea in the ticket is worth it. It's a
> two-liner if somebody wants to do this in their code, so whilst we *can*
> add this method, adding yet another thing to Model namespace that also
> adds to the documentation and things that need to be tested, etc,
> doesn't s
The re-factored code moves the definition of default widgets for each
model field into an update-able dict and uses `if dbfield.__class__ in
self.formfield_overrides` to look up the correct widget for `dbfield`
instead of using `isinstance()`.
The problem arises when using a custom model field th
Are the objections being raised for `update()` equally applicable to
`update_or_create()`?
I would have thought that a name-space clash for this method on the
objects manager would have been a non-issue, as would any confusion
about the use of `force_update` and `force_create` internally (as they
You could even put such an `ALTER TABLE` statement in a `sql/
modelname.sql` file to be executed as initial SQL data as soon as the
table is created by `syncdb`.
On Apr 8, 11:40 pm, Thomas Guettler wrote:
> Hi,
>
> I once get BigInt working by a little "ALTER TABLE ... ALTER COLUMN"
> statemen
I just noticed in recent versions of Django that BooleanField
(null=True) will raise a validation warning, indicating that I should
use NullBooleanField instead. This doesn't make sense, and is mixing
up the definition of a model field in SQL and the behaviour of a model
field in Django.
BooleanF
Right now it seems that for a generic app to support the possibility of
being installed in a URLconf with a namespace, the app author will need to
take care to explicitly define a `current_app` for every call to
`reverse()`, `TemplateResponse`, `RequestContext`, `Context` and `{% url
%}`.
Djan
>From my perspective, this issue is about silent data loss, which is about
one of the worst bugs you can have and one that Django typically tries very
hard to avoid or fix, even if it breaks compatibility.
It is extremely easy to cause silent data loss with the behaviour being
discussed. For whate
I'm -0 on this too, even though I have run into a situation where I
wanted a block to appear twice in a base template, and the content of
the block was defined in the view template (can't remember the
details). The additional complication and strange rules are not worth
the benefit (and I'm not ev
i'd like to see a single generic phone number field, and different
methods attached to it that format it to the required formats. usa,
international, including or excluding country code, using spaces or
dashes, with or without leading zeroes, etc.
--~--~-~--~~~---~--~
I use Any sender a fair bit (in a generic version control app), and
I'd not like to see that disappear without considerable performance
penalties if keeping it / considerable performance gains if removing
it.
--~--~-~--~~~---~--~~
You received this message because
+1 - it's a simple default settings change. django is used by an
international community, so the defaults should be a format that is
understood by everybody without any possibility of ambiguity. those
that prefer a different format (american, or abbreviated or full
length month names etc) can chan
I would have thought it's obvious. Any fields are are not null=True
must have a default specified in the model or a value explicitly
provided before calling save(). However, I just did a quick double-
take and it looks like CharField actually has an implicit default of
"" already. If CharField can
imo, the official documentation should not document bugs, and should
also not provide non-working examples. therefore either the bug should
be fixed immediately, or the example should be removed immediately (to
be re-instated when the bug is fixed). it is true that many bugs
remain in trunk for a
indeed, many people prefer to login with their email address, or use
their email address as their username. that way they're not likely to
forget it, and can use the same one which is guaranteed not to be in
use by anyone else across all their sites. rather than having to
remember multiple usernam
as long as django doesn't *require* a version of python that is not on
your approved list and therefore cannot run, you shouldn't have any
problems. django is built to work on python 2.3, just because it is
also compatible with 2.4 and 2.5 shouldn't mean anything. the fact
that the code still work
I've been using my own messages in sessions for a while now and every
message i send is either "good", "bad", or neutral (neither good nor
bad). these three states are very generic and cover every type of
message i need to send. at present i display good messages in green,
bad in red, and neutral
For each new site I work on I have a root folder which contains a copy
of Django, other 3rd party libs I need, and a Django project for my
site. I do this so I can upgrade or customise Django for each site
individually without breaking other sites. I'll probably switch back
to a common Django afte
I'm also +1 __nonezero__ -1 .exists(). Using .count() already gives us
the required functionality and makes logical sense, the only question
then is how big of a performance gain do we get by using SELECT 1
LIMIT 1.
SELECT 1 FROM [table] LIMIT 1 also feels kinda hackish to me, and I'm
guessing it
I think that instead of executing queries where you want to return no
records and know that no records will ever be returned if a field
lookup is None (e.g. in the case of related objects to an unsaved
object), you should just catch that condition and not execute that
query.
In 9 years I've never
On Jul 22, 8:29 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> I'm personally ambivalent about where the "include" tag should be able
> to search, because I can see cases where it'd be useful to have it
> pull in things that aren't in TEMPLATE_DIRS. If you're interested in
> confining the place
Why do you need a shared project to house generic apps? Why not just
put them at dango_root (or anywhere on your python path), and install
them in your django projects (sites)?
django_root/
genericapp1/
genericapp2/
mysite/
__init__.py
apps/
__init__.py
+1 for autoescape on by default, switched off with a tag in base
templates, applied to all templates regardless of extension.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to thi
if re-serializing the data when closing the dev server, wouldn't it be
easier to just leave it in the db and not trash/recreate the db all
the time, and manually dump/load the serialized data when necessary?
--~--~-~--~~~---~--~~
You received this message because
I'd be +1 in allowing list_display options in the form of
'model__field' ('model__model__field', ...), and I have found myself
wanting this on several occasions.
Yes it is possible to create a method and call it as a column in the
results, but I think the intention with that was more for calculat
> If there are any, then I would expect it'd handle them just as it does
> without the flag. The problem is (at least in my eyes) that Django
> should not be guessing, and especially should not be doing an extra
> query, when you are explicitly saing update or create on an object.
Django *would*
It should probably be 320, and if there are any databases that don't
support a field that long, it should be reduced to accomodate those
databases (only), rather than holding everything back for the lowest
common denominator?
--~--~-~--~~~---~--~~
You received thi
Isn't having choices (with a value and display text) already combining
presentation with the model? I don't see why having the model ignore
the groupings would be any worse than having the model ignore the
display text for each choice.
I'd really like to see nested choices / optgroups allowed in
I think I'd like to see this functionality in trunk, too. Previously
when I needed a M2M model with sequence or other data, I just created
the M2M model explicitly with ForeignKey fields to the two related
models.
class Role(models.Model):
role = models.CharField(maxlength=255)
c
I've implemented multi-column ordering in my own projects, and don't
think it's that tricky to use (in the UI, implementation may be tricky
but not too tricky). I use multi-column ordering all the time in my
apps and most desktop apps, so I'd love to see it built into the
Django admin.
In terms o
ForeignKey with unique=True does work and is the same at the SQL
level, but OneToOneField does have a couple of niceties attached to it
like adding the related object as an attribute to the model containing
the OneToOneField. If those could be re-added to ForeignKey fields
with unique=True, that w
I had previously used OneToOne relationships and liked the auto
mapping they did, as in the OP's example. I was told that OneToOne
didn't work in some cases and was going away, and that I should use
ForeignKey(unique=True) instead.
If there are technical problems with OneToOne and
ForeignKey(uniq
I think I was just bitten by this. The model fields defined in
django.contrib.auth.models (and I assume other parts of django) use
django.utils.translation.ugettext_lazy to specify the label (or
another property from which the label is derired). The form field
objects generated by form_for_* and M
Ticket opened. http://code.djangoproject.com/ticket/6272
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscr
+1 interested party ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
I'd vote for create() and update() methods which seem the least
confusing, but that doesn't seem very popular. If it has to be done
with arguments on save(), I'd say force_create=False,
force_update=False is the easiest to read and understand.
I'd prefer either of those options over a null/true/f
> Purely in terms of OO design, because it's cleaner. Object
> composition is usually a more appropriate paradigm than class
> inheritance. To take the example from the post that started this
> thread, the relationship between users and user profiles is "has-a",
> not "is-a". So what would be t
101 - 171 of 171 matches
Mail list logo
