I think one of the reasons that order_by only uses the last one is
because you have often have a default that you may want to override,
and I guess the consensus is you shouldn't have to specify to clear
the default ordering if you reorder. Whether that should apply here
I'm not sure.
On Apr 3,
> The OP suggests an additive behavior similar to the way filter()
> operates. However, there is also the option of a "last one wins" approach, as
> seen by the order_by() method (on trunk, is it the same in qs-rf?):
Although, you have a point, I have to say that limitation in order_by
bugs me a
On 4 abr, 00:28, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> What about replacing the idea of a ModelForm with a ModelField? Then
> for shorter
> forms you could list all the fields explicitly, without having to
> recode all the
> default field definitions.
I think should be hard to implemen
What about replacing the idea of a ModelForm with a ModelField? Then
for shorter
forms you could list all the fields explicitly, without having to
recode all the
default field definitions.
e.g.:
class MyForm(forms.Form):
foo = forms.ModelField(SomeModel, 'foo', widget=forms.Textarea)
bar
> OK, sourceforge's SVN is back up and from a brief look I don't think the tip
> of the trunk for MySQLdb is intended to be in general use. The comment
> associated with rev 530, current for connections.py and the one which
> introduced this change is: "Tons of changes from major refactoring/clea
On Thu, Apr 3, 2008 at 2:55 PM, Tim Keating <[EMAIL PROTECTED]> wrote:
>
> I got 1.3.0 by syncing to the svn trunk. The definition of a
> connection in 1.3.0 looks like this:
>
> class Connection(object):
>"""MySQL Database Connection Object"""
>
> So if there previously was an inheritance rel
On Thu, Apr 3, 2008 at 2:55 PM, Tim Keating <[EMAIL PROTECTED]> wrote:
>
> On Apr 3, 2:39 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> > On Thu, Apr 3, 2008 at 2:18 PM, Tim Keating <[EMAIL PROTECTED]> wrote:
> >
> > > I should clarify - this is with MySQLdb 1.3.0 built from source, MySQL
> > >
On Apr 3, 2:39 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 3, 2008 at 2:18 PM, Tim Keating <[EMAIL PROTECTED]> wrote:
>
> > I should clarify - this is with MySQLdb 1.3.0 built from source, MySQL
> > 5.0.41 and Python 2.5.
>
> Where did you get MySQLdb 1.3.0? Latest I see at source
On Thu, Apr 3, 2008 at 2:18 PM, Tim Keating <[EMAIL PROTECTED]> wrote:
>
> I should clarify - this is with MySQLdb 1.3.0 built from source, MySQL
> 5.0.41 and Python 2.5.
>
Where did you get MySQLdb 1.3.0? Latest I see at sourceforge (
https://sourceforge.net/project/showfiles.php?group_id=22307
I should clarify - this is with MySQLdb 1.3.0 built from source, MySQL
5.0.41 and Python 2.5.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-deve
Sorry, one more thought. Told you I'm not scared of writing!
Regarding hand-rolling these processes: yes, that's easy to do. But
automatic data generation is part of the greater testing process that
production code needs to undergo. And when you hand-roll testing
processes on the fly, you have to
I have recently set up Django with MySQL on Mac OS X 10.5. I am
running into the following error:
File "/Users/tkeating/Documents/Projects/django/django/db/backends/
mysql/base.py", line 196, in get_server_version
m = server_version_re.match(self.connection.get_server_info())
AttributeError
Mike Axiak said the following:
> Let me reiterate a position that I posted on #6941. After reviewing, I
> actually *don't* think we're all that muddled. A session is
> {{{request.session}}} and is represented by the browser's session.
> Whereas a user is {{{request.user}}} and is completely separa
> The main part of your application is something I'll think about some
> more, but I'm not really sure what development effort is involved there.
To address this particular point a little more:
My original proposal was lean on details, which is entirely my fault.
To be honest, I've never partici
Malcolm,
Regarding model-level validation, apparently I'm bad at tracking down
information. I tried on a couple of occasions to search for
information on validation's progress and only found references to
discussions that weren't recorded therein. My mistake. I'm glad that's
already so far along;
On Thu, Apr 3, 2008 at 9:07 AM, Aaron <[EMAIL PROTECTED]> wrote:
> My apologies in advance if this is not the correct channel for this
> message,
It is not. From the group's description:
"""
Discussion group for Django developers. This group is used for
discussion of developing Django itself,
My apologies in advance if this is not the correct channel for this
message, but we have struggled to find this expertise and are now
reaching out to the community. HBK is a multi-strategy hedge fund
based in Dallas, TX (with office around the world) who is looking for
a web 2.0 guru to lead & he
On Thu, Apr 3, 2008 at 9:03 AM, lep_man <[EMAIL PROTECTED]> wrote:
>
> HI Guys
>
> i have buit an application that read tasks from db and execute them ,i
> using django to get a connection to the db (i have crated a Task Class
> (uses django models) my server reads every ten secs a list of task an
HI Guys
i have buit an application that read tasks from db and execute them ,i
using django to get a connection to the db (i have crated a Task Class
(uses django models) my server reads every ten secs a list of task and
excutes them (my server is a multithreaded and has a thread that read
from t
Sorry, as usual, I wasn't clear. When I said "at least in part" I
didn't express my thoughts very well.
I don't mean that high level or in depth discussion should be taking
place in the doc strings, that's for your excellent blog posts (and
the docs, of course)!.
But it doesn't hurt to have cla
On Apr 3, 8:23 pm, mrts <[EMAIL PROTECTED]> wrote:
> > After reading through these, I think most of these can be satisfied
> > with the proper session backend. Why not write a "secure" session
> > backend? (You would presumably also need to require signed cookies for
> > the session.) I would be i
> After reading through these, I think most of these can be satisfied
> with the proper session backend. Why not write a "secure" session
> backend? (You would presumably also need to require signed cookies for
> the session.) I would be interested to see what it would look like.
I think a genera
On Apr 3, 4:36 am, mrts <[EMAIL PROTECTED]> wrote:
> Quoting #6941:
> [4:17pm] jacobkm: Also, there's the question of whether the session is
> tied to the browser or to the user -- we're a bit muddled there
> currently.
Let me reiterate a position that I posted on #6941. After reviewing, I
actual
SessionStore is missing a clear() or invalidate() method that will
destroy the session. Is this intentional? If so, why? Cleaning a
session is such a common requirement for session frameworks.
Looking through tickets, I found the following relevant to general
session logic (in no particular order
24 matches
Mail list logo
