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 woul
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 wantin
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 ma
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 be
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 another
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 :)
Ja
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 I
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 t
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 al
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* .get(pk=1)
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 c
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
>>> UserProfile.objects.create(user_i
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 :)
--
Colli
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 argum
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 a
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 c
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 h
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 furth
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 django-openi
> 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 speak
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 magicall
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.
> Please,
> 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 admit"
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 measur
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 rem
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 Message--
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 update/i
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, w
I'm working on the splitting of the beasts residing on
tests/regressiontests/forms. Motivations: They (tests.py and
localflavors.py) are too big for human consumption. And for Jython
consumption too (strings constants can't be longer than 32Kbytes).
I've already splitted localflavors into one fil
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 B
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 indicat
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
> Us
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) #Current
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 numbe
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) #Currently
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
UserProfile.objects.get(user_id=3) #Currently does not
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 system)
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
On 9/19/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> class Membership(models.Model):
> def add(self, user, guild):
> if user.guild_set.count() > 3:
> raise Exception, "Maximum guild membership has been reached."
> super(Membership, self).add(user, guild)
Pardon th
Maybe there should be a .truncate()? Heh.
Matt
-Original Message-
From: django-developers@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Hudson
Sent: Tuesday, September 18, 2007 10:15 PM
To: Django developers
Subject: Is model.objects.all().delete() optimized to use DELET
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 t
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 i
49 matches
Mail list logo
