On Tue, Jul 24, 2007 at 06:52:54PM -0500, Adrian Holovaty wrote:
>
> On 7/24/07, Scott Paul Robertson <[EMAIL PROTECTED]> wrote:
> > [ Discusion about editor for development wiki pages... ]
> > Since I'm throwing out the idea, I'm willing to do this. Is any one else
> > interested?
>
> This
Yuri Baburov wrote:
> For me, the process of developing Queryset refactoring totally went
> out of control. And everyone says that "all will be outdated after
> queryset refactoring release so we won't do anything now."
As mentioned by someone else in this thread, this is partly due to not
Yuri Baburov wrote:
> Do you need more committers/triagers?
Yes, always. This has been discussed, and we will promote those who deserve
it. For those wanting to know how to become committers or triagers, well, I
can tell you how I did it:
1. Spend lots of time using Django.
2. Take part in
On 9/19/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> What is the reasoning (or is there any) behind setting an object's pk
> to None before sending the post_delete signal? A swapping of lines [1]
> would change it. I could just listen for the pre_delete signal, but I
> don't actually want
Collin Grady wrote:
> David Cramer said the following:
>> I don't believe .create() allows you to say myforeignkey=1, correct me
>> if I'm wrong, but I think it throws an error about it needing to be a
>> instance.
Yes, you are correct.
> But .create() already works with fkeyname_id, it's just
> I think Jacob has been _extraordinarily_ polite, considering some of
> the comments you have made.
Yes, thanks. I talked with him personally off-list and he seems to
understand my position. We discussed some of the important points, and
he said i did few good suggestions.
That was reached not
On 9/20/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> > If there's a connection between politeness and commit access, it's not
> > an accident.
> It's not that hard to be polite when you have power and are
> unconsciously trying to get more reputation.
Just to weigh in with the voice of
On 9/19/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> It seems that the diff format isn't the best way to comunicate file
> deletions: regressiontests/forms/localflavor.py should be removed, but
> it's still alive on SVN, without any content.
Whoops, deleted, thanks.
Jacob
On 9/19/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 9/19/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> > Well, I did it, see: http://code.djangoproject.com/ticket/5546
>
> Committed in [6379] -- thanks a bunch for the grunt work. The length
> of that file was starting to annoy me :)
On 9/19/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> Well, I did it, see: http://code.djangoproject.com/ticket/5546
Committed in [6379] -- thanks a bunch for the grunt work. The length
of that file was starting to annoy me :)
Oh, and I agree that these sub-tests ought to be autodiscovered, but
On 9/19/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> I'm working on the splitting [...]
Well, I did it, see: http://code.djangoproject.com/ticket/5546
Please, if someone is currently working on such tests, ping me so I
can update the split version and post another patch. Or wait a bit for
this
Jacob Kaplan-Moss said the following:
> That is, make::
>
> Foo.objects.get_or_create(bar__id=1)
>
> Work the same way as::
>
> Foo.objects.get_or_create(bar__id=1, defaults={"bar_id": 1})
That would probably be better than the current, but I'm still on David's
side in thinking that
James Bennett said the following:
> 1. The lookup syntax *always* uses double underscores for relations.
But checking fkey_id isn't trying to cross the relation - it wants the
local value :)
> 2. The lookup syntax *only* lets you look up by things that actually are
> fields.
*cough*
On 9/19/07, Collin Grady <[EMAIL PROTECTED]> wrote:
> But .create() already works with fkeyname_id, it's just get() and
> get_or_create() that don't :)
So seems to me the best way to solve this is to make get_or_create()
understand how to swizzle a lookup of the form "fk__id" or "fk__pk"
into a
On 9/19/07, David Cramer <[EMAIL PROTECTED]> wrote:
> I don't believe .create() allows you to say myforeignkey=1, correct me
> if I'm wrong, but I think it throws an error about it needing to be a
> instance.
OK, so let's do this exhaustively.
>>> my_id = 3
>>>
David Cramer said the following:
> I don't believe .create() allows you to say myforeignkey=1, correct me
> if I'm wrong, but I think it throws an error about it needing to be a
> instance.
But .create() already works with fkeyname_id, it's just get() and
get_or_create() that don't :)
--
I don't believe .create() allows you to say myforeignkey=1, correct me
if I'm wrong, but I think it throws an error about it needing to be a
instance.
On Sep 19, 11:30 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 9/19/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > Yes, my biggest
2007/9/20, Jacob Kaplan-Moss <[EMAIL PROTECTED]>:
>
> On 9/19/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> > I'm willing to add schema-evolution into django.
>
> Sweet! I can't wait to see the code!
It is not that big, and will not be (if I will do it).
It was patch of 10 changed files 2 months
2007/9/20, Marty Alchin <[EMAIL PROTECTED]>:
>
> One thing we have to keep in mind here is that people regularly use
> the SVN version of Django, so it needs to be working as well as
> possible, all the time. This is unlike many other projects, where the
> repository (be it SVN or CVS) is always
Yuri Baburov said the following:
> 4) why it stopped other valuable changes of that part of code, like
> aggregates support?
> I just think you are trying to do much more than was necessary in that
> branch. That's why it takes so long.
Because there's no point doing the work on something that's
On 9/19/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> 1) when it's going to be ready,
When it's done.
> 2) why it's still not ready,
Because we're *volunteers*, and we have real lives, friends, jobs, and
other responsibilities.
Want it faster? Contribute code, or pay a core developer so that
Let me just add a coda onto this discussion:
Remember pluggable file-storage? Yeah, that would have been checked in
by now if I hadn't let myself get sucked into this pointless argument.
So this is last I'm gonna say on the manner.
Yuri, if you -- or anyone, really -- want to discuss this
On 9/19/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> I'm willing to add schema-evolution into django.
Sweet! I can't wait to see the code!
However, I don't see what this has to do with commit access. The right
way to develop a feature of this size is as a third-party project --
see
> This is a public mailing list. You don't get to decide who
> participates in discussions. Furthermore, Deryck has been a valued
> member of Django's development community for quite some time, and also
> contributes another high-profile open-source project (Samba). He's
> quite qualified to
One thing we have to keep in mind here is that people regularly use
the SVN version of Django, so it needs to be working as well as
possible, all the time. This is unlike many other projects, where the
repository (be it SVN or CVS) is always considered a work-in-progress,
where users are urged to
On 9/19/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> > I won't presume to speak for the core devs, but who wouldn't answer
> > "yes" to the question of need for more committers! :-)
> Then we need the "process of becoming committer".
> I don't want a worthless discussion on this question, like
2007/9/20, Jacob Kaplan-Moss <[EMAIL PROTECTED]>:
>
> On 9/19/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> > Do you need more committers/triagers?
>
> Yes.
>
> Please send a couple in a mint-condition 1968 El Camino in bumblebee
> yellow with a thick double black racing stripe, competition tires
Tom Tobin said the following:
> *Way* -1. I don't want to be looking at code and wondering whether a
> particular query is dealing with a local field named "foo_bar" or a
> related model "foo" with a field "bar".
Except when you do user__id it /is/ referring to the local column, it
just
On 9/19/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> Then we need the "process of becoming committer".
http://www.djangoproject.com/documentation/contributing/#commit-access
That's been there for over a year.
> I don't want a worthless discussion on this question, like one month ago.
>
> I won't presume to speak for the core devs, but who wouldn't answer
> "yes" to the question of need for more committers! :-)
Then we need the "process of becoming committer".
I don't want a worthless discussion on this question, like one month ago.
Please, only core devs, and only "Yes, I
On 9/19/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> Do you need more committers/triagers?
Yes.
Please send a couple in a mint-condition 1968 El Camino in bumblebee
yellow with a thick double black racing stripe, competition tires and
an LS6 450hp engine with turbocharge option. For good
On 9/19/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> Dear Django core developers,
>
> Do you need more committers/triagers?
>
> Reasons for:
> * Opened tickets count is increasing faster then decreasing.
> * Community is growing and expanding fast.
> * Simple bugs are not fixed.
> * Tickets
TRUNCATE has transactional side effects, so I'm +1 on adding
model.objects.truncate(), -1 on optimizing
model.objects.all().delete().
Ian
On 9/19/07, Wensing, Matthew (CNI-Palm Beach) <[EMAIL PROTECTED]> wrote:
>
> Maybe there should be a .truncate()? Heh.
>
> Matt
>
>
> -Original
On 9/19/07, David Cramer <[EMAIL PROTECTED]> wrote:
> Yes, my biggest argument is I want to use .get_or_create() and I don't
> have an instance of the row (the id) I'm trying to insert. I'm *not*
> going to query for this instance (I'll write SQL before I add extra
> queries just to do an
Yes, my biggest argument is I want to use .get_or_create() and I don't
have an instance of the row (the id) I'm trying to insert. I'm *not*
going to query for this instance (I'll write SQL before I add extra
queries just to do an update/insert), and I don't like creating a fake
temporary object,
I +1 on truncate, I'd suggest submitting a ticket
On Sep 19, 5:17 am, "Wensing, Matthew \(CNI-Palm Beach\)"
<[EMAIL PROTECTED]> wrote:
> Maybe there should be a .truncate()? Heh.
>
> Matt
>
> -Original Message-
> From: django-developers@googlegroups.com
>
> [mailto:[EMAIL PROTECTED] On
The following are assumptions I would make if both "worked".
> UserProfile.objects.get(user__id=3) #Currently works
This is obviously a foreign key and clearly refers to the id field of
the User model. Nuf' said.
> UserProfile.objects.get(user_id=3) #Currently does not work
There is no
On Wed, Sep 19, James Bennett wrote:
>
> David Cramer has asked that Django's ORM lookup syntax be changed to
> allow a single underscore for a foreign key lookup; in other words,
> the following two examples would become equivalent:
>
> UserProfile.objects.get(user__id=3) #Currently works
>
On 9/19/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> David Cramer has asked that Django's ORM lookup syntax be changed to
> allow a single underscore for a foreign key lookup; in other words,
> the following two examples would become equivalent:
>
> UserProfile.objects.get(user__id=3)
Dear Django core developers,
Do you need more committers/triagers?
Reasons for:
* Opened tickets count is increasing faster then decreasing.
* Community is growing and expanding fast.
* Simple bugs are not fixed.
* Tickets remains opened for months.
* Ticket code become outdated after some
On 9/19/07, James Bennett <[EMAIL PROTECTED]> wrote:
> David Cramer has asked that Django's ORM lookup syntax be changed to
> allow a single underscore for a foreign key lookup; in other words,
> the following two examples would become equivalent:
>
> UserProfile.objects.get(user__id=3)
What is the reasoning (or is there any) behind setting an object's pk
to None before sending the post_delete signal? A swapping of lines [1]
would change it. I could just listen for the pre_delete signal, but I
don't actually want to do what I'm going to do (remove some data in an
external
Matt,
I'm having difficulty reproducing this error, as the objects I create
from the admin save ok.
Can you provide the code for your model and/or a more verbose
traceback? Are you using psycopg2? Have you modified any parts of
the code, especially any GEOS components?
I ask because the GEOS
I agree that a favicon is one of those fit-and-finish touches that helps
complete a website. Attached are my attempts. I agree with Todd that
"dj" is a better reminder of Django, and the color should be greener
(look at the badges to see that Wilson didn't slavishly follow the deep
green of
On 9/19/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> It sounds like you're talking about making the m2m table a 3 foreign
> key affair (with the third foreign key referencing the intermediate
> data) rather than just adding 2 foreign keys (from and to) to the
> intermediate model. I'd be
Also Jacob, on the documentation the link ot the contenttypes docs have gone
missing. As well as a few other documentation files that don't seem to be on
the index link.
Is this intentional?
On 9/19/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 2007-09-18 at 15:51 -0500, Jacob
46 matches
Mail list logo
