Hi all,
For those who don't follow the Django community aggregator I thought
I'd send this out to the lists. I'm arranging an informal get-together
of Django folks next month here in Northampton, MA.
http://open.e-scribe.com/wiki/DjangoDotJune
Here's a condensed version of the info from that p
Just wanted to offer my thanks to Adrian (and anybody else who worked
on this) for adding some spam defense to the Trac server. For those of
us who check the timeline often, it's a big relief.
pb
--
Paul Bissex
http://e-scribe.com/news/
Northampton MA USA 01061-0847
--~--~-~--~~--
> ValueError: year is out of range
>
> I'm not sure why "year is out of range" is a problem - maybe because
> the table has TIMESTAMP column types?
It's probably because you have invalid data (like -00-00) in those
columns. I encountered this on some of my legacy MySQL tables. In my
case I ma
> I was thinking about a nice addition to Django where you would keep
> your old model files around and offer a few utility classes to do the
> diff / alter output for you. But your idea is a nice immediate step.
There's some discussion of that idea here:
http://code.djangoproject.com/wiki/Sch
Ned, can you elaborate on what you dislike about combining the field
definitions and the helper functions together in one file?
As a practical matter I find that I need to have the model at hand to
write helper functions, so for that reason alone I've come to
appreciate having them all together,
Here's another way to look at it, given that we are still at 0.91+:
Besides inertia, what are the arguments in favor of the system Django
currently uses? The only person I've seen address this is Jacob, who
correctly noted in the ticket comments that some beginners would find
the separate settings
> It looks impossible on the SQL side. I thought you coud join tables,
> order by a field in authors table and then get results with DISTINCT to
> eliminate duplication from joining. But it appears that DISTINCT
> requires you to select fields that you order by which ensures that
> duplication wou
> Hi, I'm still new to django and have googled high and low for a way to
> use a single dsn in the settings file instead of DATABASE_HOST,
> DATABASE_USER, DATABASE_NAME, etc. No metion of it. Is there built
> in support for this that I'm missing?
>
> If not, I am happy to submit a patch.
+1. I
> I haven't seen any patches that add this functionality. Here are a
> couple of stop-gap solutions:
> * She could bookmark the filtered change-list page and return to it
> after editing the object.
>
> * From the filtered change-list page, she could open the
> object-editing page in a new browse
I have a request from one of my admin users which seems reasonable, but
I don't know how to satisfy it.
She would like to have the admin "remember its place" when she edits
individual records. That is, if she filters by X and Y criteria, then
goes to the second page of results, then edits a singl
> plugging the FK field into the ordering clause produces an
> OpertationalError, "Unknown table
> 'RELATED_TABLE_THAT_MOST_CERTAINLY_IS_KNOWN' in order clause."
Sorry, I meant to say specifically that this happens when I search in
the admin.
pb
--~--~-~--~~~---~--~
This may be a dumb question but I've been banging my head against it
for a while. Two questions, actually.
(I'm using the M-R branch.)
1) How can I use a field in a related model in a Meta.ordering clause?
E.g. I want my Articles sorted by Reporter.lastname
2) How can I use a computed value in
I had a frustrated user today whose seemingly valid input into an
IntegerField was getting rejected at the validation step (using my
model's default manipulator). We eventually discovered a stray space at
the end of his input.
Is there a reason that formfield values destined for numeric Django
mo
> it's not really in the scope of the admin to display
> information that can't be edited. Anything along those lines is
> probably a candidate for customization
I'll buy that.
Admin customization tips (in addition to reading the source) would be
welcome at this point. I thought I had seen some,
I think rolling functionality similar to ABSOLUTE_URL_OVERRIDES into
URLconfs is the way to go. As others have pointed out,
get_absolute_url() doesn't cover enough ground and creates unnecessary
coupling.
Simon expresses it well here:
http://groups.google.com/group/django-developers/msg/98ee1a
When viewing one object in the admin (say, a Landlord) I'd like to be
able to display a list of related objects (say, Properties). The
edit_inline feature is overkill, because the Properties don't need to
be edited in place -- and they have too many fields to fit comfortably
inline anyway.
Basica
Adrian said:
> I've never used Dreamhost, but I'll just toss in my two cents that
> having a dedicated server, with root access, is well worth it.
> ... it's still kinda-sorta affordable in the grand scheme
> of things if you're serious about making Web apps.
I totally agree. It's great to have r
17 matches
Mail list logo
