Threading review wiki page removal

[mrts]

James has replaced the content of

http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading

with the following disclaimer:

"This page and several others were created by a
wiki user who was not and is not a member of the
Django core team. Previous contents of this and
other similar pages are not and should not be confused
with Django's own documentation, which remains
the sole source of official documentation for the Django project."

I personally think that the information on that page [1]
was both useful and mostly correct, albeit incomplete.
As such I fail to see why it should be removed --
the disclaimer given by James pertains to the majority
of pages in Django wiki; following that reasoning,
all of them should be removed :).
(Moreover, the disclaimer is implicit in most wikis' content.)

That doesn't necessarily mean that the page should be
restored as-is. Something seems to disturb James,
so the contents should perhaps be updated, amended
and relocated to a better URL so that he and other members
of the core would be happy with it instead.

Thoughts?

Best,
Mart Sõmermaa

[1] Original content:
http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading?version=80

P.S. I'm the author of that page, but that's not really important.
What is important -- there was information on a core
aspect of Django not available anywhere else which helps
others to understand it better and write better patches for it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Bug #348 and Safari.

[schinckel]

It seems Safari (Mac, at least) is still plagued by what seems to be
the behaviour described by http://code.djangoproject.com/ticket/348 -
when you have a ManyToMany, and have turned it into a javascript-
enabled filter box pair (SelectFilter2.js), then you get funky
behaviour.

This is fine in Firefox/Camino, but still has duplicates (and no
pattern to them that I could find).

Is this reason enough to reopen this ticket?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Bug #348 and Safari.

[Jacob Kaplan-Moss]

On Tue, Apr 6, 2010 at 9:42 AM, schinckel  wrote:
> It seems Safari (Mac, at least) is still plagued by what seems to be
> the behaviour described by http://code.djangoproject.com/ticket/348 -
> when you have a ManyToMany, and have turned it into a javascript-
> enabled filter box pair (SelectFilter2.js), then you get funky
> behaviour.
>
> This is fine in Firefox/Camino, but still has duplicates (and no
> pattern to them that I could find).
>
> Is this reason enough to reopen this ticket?

A new ticket would be better -- browsers have changed a lot since
Firefox 1.0.6 (wow, Django's OLD!) -- and the bug's likely to be
different. You can reference #348 and mention it seems similar, but a
fresh ticket without all the old history would be preferable in this
case.

Also, please be sure to more clearly define what's going on. You've
told us that "Safari" on "Mac" has "funky behavior"; we're going to
need more specific information to track it down. In particular, we
need:

* Your Django version.
* Your ModelAdmin declaration.
* What version of Safari you're running.
* What version of Mac OS X you're running.
* A clear definition of "funky behavior". A screenshot -- or even
video -- would help loads.

If you want brownie points, you'll try to reproduce the bug in related
browsers (Safari on Windows? WebKit nightlies? Chrome?)

Yes, I know it's a lot to do, but unfortunately tracking down
JavaScript-related browser bugs is the *worst*, so we need all the
help we can get!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Threading review wiki page removal

[Russell Keith-Magee]

On Tue, Apr 6, 2010 at 8:56 PM, mrts  wrote:
> James has replaced the content of
>
> http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading
>
> with the following disclaimer:
>
> "This page and several others were created by a
> wiki user who was not and is not a member of the
> Django core team. Previous contents of this and
> other similar pages are not and should not be confused
> with Django's own documentation, which remains
> the sole source of official documentation for the Django project."
>
> I personally think that the information on that page [1]
> was both useful and mostly correct, albeit incomplete.
> As such I fail to see why it should be removed --
> the disclaimer given by James pertains to the majority
> of pages in Django wiki; following that reasoning,
> all of them should be removed :).
> (Moreover, the disclaimer is implicit in most wikis' content.)
>
> That doesn't necessarily mean that the page should be
> restored as-is. Something seems to disturb James,
> so the contents should perhaps be updated, amended
> and relocated to a better URL so that he and other members
> of the core would be happy with it instead.
>
> Thoughts?

James spoke with me about this decision at the time, and I completely
agree with and endorse his actions.

While it is true that wikis contain all sorts of information, often
unofficial, the naming of the wiki pages in question --
DjangoSpecifications/Core -- conveyed a *very* strong signal that the
information contained was official in some capacity. Regardless of the
merits of the information on that page, the simple fact remains that
it *isn't* official, and it *wasn't* vetted or edited by anyone in the
core.

It isn't just a matter of moving it somewhere else in the wiki,
either. The simple fact remains that the wiki is housed on
djangoproject.com, and it's impossible to tell what is official and
correct information, and what is not. This doesn't matter so much when
we're discussing the location and participants in an upcoming sprint
or brainstorming design ideas for a proposal, but it matters a great
deal when a page is describing long term architectural decisions or
guidelines.

Django's position on "core specifications" is that:
 * If there is a bug, it should be logged in Trac, and (ideally) fixed
 * If there is some usage guidelines that need to documented, they
should be documented formally and integrated into Django's own
documentation.

If you think there is some valuable information in the wiki pages that
were deleted, then you need to turn that information into either
tickets in Trac, or a draft for addition to the official
documentation. If you think there is some information on that page
that doesn't fit into the official locations that Django currently
provides, then we need to have a meta-discussion around the right
place to house information of that sort.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Bug #348 and Safari.

[schinckel]

On Apr 7, 12:20 am, Jacob Kaplan-Moss  wrote:
> On Tue, Apr 6, 2010 at 9:42 AM, schinckel  wrote:
[snip]
>
> A new ticket would be better -- browsers have changed a lot since
> Firefox 1.0.6 (wow, Django's OLD!) -- and the bug's likely to be
> different. You can reference #348 and mention it seems similar, but a
> fresh ticket without all the old history would be preferable in this
> case.

> Also, please be sure to more clearly define what's going on. You've
> told us that "Safari" on "Mac" has "funky behavior"; we're going to
> need more specific information to track it down. In particular, we
> need:

Yeah, I was going to put all that in - was just after the decision to
reopen the old ticket or create a new one.

As it turns out, the bug seems to have been fixed by the Webkit build
I just grabbed.  So clearly that was where the bug was, not in the
django javascript.

Matt.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Tiny, tiny patch - can it make it into Django 1.2?

[David Reynolds]

Hi,

Just thought I'd ask whether or not http://code.djangoproject.com/ticket/10917 
would be able to make it into Django 1.2?

I know now is not the greatest time to ask, but it seems like a fairly tiny 
change that would help to make the new messages framework a lot more flexible 
when customising the admin site.

Thanks,

David
-- 
David Reynolds
da...@reynoldsfamily.org.uk

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

GSOC Django housekeeping

[Elayne Morais]

Hello!

This is my first time at GSoC and I'm sure that coding for Django will
be very interesting. As I don't have experience with Django I thought
the best project for me would be doing some housekeeping, which at the
same time would give me a wider understanding of Django inside out.
However, I read others students had the same idea, so here are my
questions:

- how many students Django will be able to select?
- will be possible more than one student working at the same project?
(like 2 students doing housekeeping on different parts of the code)
- do I need to be specific on what part of the code I'll be doing the
housekeeping, or I can just say I'll be doing a general housekeeping?
My concern is about the timeline: how will I be able to say I have
finished coding?
- can I keep on coding for Django after GSoC if I want?

Thank you all.

Elayne.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSOC Django housekeeping

[Alex Gaynor]

On Tue, Apr 6, 2010 at 11:58 AM, Elayne Morais  wrote:
> Hello!
>
> This is my first time at GSoC and I'm sure that coding for Django will
> be very interesting. As I don't have experience with Django I thought
> the best project for me would be doing some housekeeping, which at the
> same time would give me a wider understanding of Django inside out.
> However, I read others students had the same idea, so here are my
> questions:
>
> - how many students Django will be able to select?

We don't know until after the application process finishes.

> - will be possible more than one student working at the same project?
> (like 2 students doing housekeeping on different parts of the code)

Maybe.  Housekeeping would probably be ok to have multiple students on
(especially if they were in different parts of the codebase).

> - do I need to be specific on what part of the code I'll be doing the
> housekeeping, or I can just say I'll be doing a general housekeeping?
> My concern is about the timeline: how will I be able to say I have
> finished coding?

Yes, your proposal should specify what areas of DJango you'll be doing
housekeeping in, including references to specific tickets where
possible.

As for how to know when you're done on this project it'd probably just
be until you've either run out of bugs (god help us ;)) or the time is
over, housekeeping is obviuosly a little open ended so you're project
would mostly be judged by how well you're doing at finding and closing
tickets.

> - can I keep on coding for Django after GSoC if I want?
>

Absolutely, one of the major goals of GSOC is to get students involved
in open source even beyond the end of their project.

> Thank you all.
>
> Elayne.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSOC Django housekeeping

[elayne]

Thank you Alex!

Just one question remains: you said you dont know how many students you'll
be able to select until the application process finishes. How does it work?

And one more thing: is there any critical part of Django that needs
housekeeping?


Thanks again.

Elayne.

On Tue, Apr 6, 2010 at 2:15 PM, Alex Gaynor  wrote:

> On Tue, Apr 6, 2010 at 11:58 AM, Elayne Morais 
> wrote:
> > Hello!
> >
> > This is my first time at GSoC and I'm sure that coding for Django will
> > be very interesting. As I don't have experience with Django I thought
> > the best project for me would be doing some housekeeping, which at the
> > same time would give me a wider understanding of Django inside out.
> > However, I read others students had the same idea, so here are my
> > questions:
> >
> > - how many students Django will be able to select?
>
> We don't know until after the application process finishes.
>
> > - will be possible more than one student working at the same project?
> > (like 2 students doing housekeeping on different parts of the code)
>
> Maybe.  Housekeeping would probably be ok to have multiple students on
> (especially if they were in different parts of the codebase).
>
> > - do I need to be specific on what part of the code I'll be doing the
> > housekeeping, or I can just say I'll be doing a general housekeeping?
> > My concern is about the timeline: how will I be able to say I have
> > finished coding?
>
> Yes, your proposal should specify what areas of DJango you'll be doing
> housekeeping in, including references to specific tickets where
> possible.
>
> As for how to know when you're done on this project it'd probably just
> be until you've either run out of bugs (god help us ;)) or the time is
> over, housekeeping is obviuosly a little open ended so you're project
> would mostly be judged by how well you're doing at finding and closing
> tickets.
>
> > - can I keep on coding for Django after GSoC if I want?
> >
>
> Absolutely, one of the major goals of GSOC is to get students involved
> in open source even beyond the end of their project.
>
> > Thank you all.
> >
> > Elayne.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> > For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >
> >
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSOC Django housekeeping

[Alex Gaynor]

On Tue, Apr 6, 2010 at 1:48 PM, elayne  wrote:
> Thank you Alex!
>
> Just one question remains: you said you dont know how many students you'll
> be able to select until the application process finishes. How does it work?
>
> And one more thing: is there any critical part of Django that needs
> housekeeping?
>
>
> Thanks again.
>
> Elayne.
>
> On Tue, Apr 6, 2010 at 2:15 PM, Alex Gaynor  wrote:
>>
>> On Tue, Apr 6, 2010 at 11:58 AM, Elayne Morais 
>> wrote:
>> > Hello!
>> >
>> > This is my first time at GSoC and I'm sure that coding for Django will
>> > be very interesting. As I don't have experience with Django I thought
>> > the best project for me would be doing some housekeeping, which at the
>> > same time would give me a wider understanding of Django inside out.
>> > However, I read others students had the same idea, so here are my
>> > questions:
>> >
>> > - how many students Django will be able to select?
>>
>> We don't know until after the application process finishes.
>>
>> > - will be possible more than one student working at the same project?
>> > (like 2 students doing housekeeping on different parts of the code)
>>
>> Maybe.  Housekeeping would probably be ok to have multiple students on
>> (especially if they were in different parts of the codebase).
>>
>> > - do I need to be specific on what part of the code I'll be doing the
>> > housekeeping, or I can just say I'll be doing a general housekeeping?
>> > My concern is about the timeline: how will I be able to say I have
>> > finished coding?
>>
>> Yes, your proposal should specify what areas of DJango you'll be doing
>> housekeeping in, including references to specific tickets where
>> possible.
>>
>> As for how to know when you're done on this project it'd probably just
>> be until you've either run out of bugs (god help us ;)) or the time is
>> over, housekeeping is obviuosly a little open ended so you're project
>> would mostly be judged by how well you're doing at finding and closing
>> tickets.
>>
>> > - can I keep on coding for Django after GSoC if I want?
>> >
>>
>> Absolutely, one of the major goals of GSOC is to get students involved
>> in open source even beyond the end of their project.
>>
>> > Thank you all.
>> >
>> > Elayne.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Django developers" group.
>> > To post to this group, send email to django-develop...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > django-developers+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/django-developers?hl=en.
>> >
>> >
>>
>> Alex
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your
>> right to say it." -- Voltaire
>> "The people's good is the highest law." -- Cicero
>> "Code can always be simpler than you think, but never as simple as you
>> want" -- Me
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

Google assigns us some number of slots.  From my memory: 2 years ago
is was 3/4 slots, last year we had 6.  We don't know how many we'll
get this year.

As for "critical" it's a bit hard to say, if anything were truly
violently broken we wouldn't be preparing for a release ;)  that being
said the admin and the ORM tend to have the most open bugs of any
component, mostly because they are 2 of the most prominent parts of
the framework.  THe best way to tell is to browse through trac's
ticket browser: http://code.djangoproject.com/query

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Tiny, tiny patch - can it make it into Django 1.2?

[Jacob Kaplan-Moss]

On Tue, Apr 6, 2010 at 11:17 AM, David Reynolds
 wrote:
> Hi,
>
> Just thought I'd ask whether or not 
> http://code.djangoproject.com/ticket/10917 would be able to make it into
> Django 1.2?

No. It's a feature addition, and we're well past feature freeze.

Sorry,

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSOC Django housekeeping

[Jacob Kaplan-Moss]

On Tue, Apr 6, 2010 at 12:52 PM, Alex Gaynor  wrote:
> Google assigns us some number of slots.  From my memory: 2 years ago
> is was 3/4 slots, last year we had 6.  We don't know how many we'll
> get this year.

We actually request a certain number of slots, and Google uses our
suggestion along with the number of good proposals to come up with the
final number. Typically we ask for as many slots as we have great
proposals, and historically we've gotten exactly what we ask for.

Of course past performance doesn't imply future, but the message
should be that if you write an awesome proposal, and if you appear to
have the chops to back it up, then you've got a very good chance of
being accepted.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSOC Django housekeeping

[elayne]

Thank you! I'll try my best!

On Tue, Apr 6, 2010 at 3:58 PM, Jacob Kaplan-Moss wrote:

> On Tue, Apr 6, 2010 at 12:52 PM, Alex Gaynor 
> wrote:
> > Google assigns us some number of slots.  From my memory: 2 years ago
> > is was 3/4 slots, last year we had 6.  We don't know how many we'll
> > get this year.
>
> We actually request a certain number of slots, and Google uses our
> suggestion along with the number of good proposals to come up with the
> final number. Typically we ask for as many slots as we have great
> proposals, and historically we've gotten exactly what we ask for.
>
> Of course past performance doesn't imply future, but the message
> should be that if you write an awesome proposal, and if you appear to
> have the chops to back it up, then you've got a very good chance of
> being accepted.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Tiny, tiny patch - can it make it into Django 1.2?

[David Reynolds]

On 6 Apr 2010, at 19:54, Jacob Kaplan-Moss wrote:

>> Just thought I'd ask whether or not 
>> http://code.djangoproject.com/ticket/10917 would be able to make it into
>> Django 1.2?
> 
> No. It's a feature addition, and we're well past feature freeze.

No problem, just thought I'd ask.

Sorry for the noise.

Thanks,

David

-- 
David Reynolds
da...@reynoldsfamily.org.uk

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Threading review wiki page removal

[mrts]

On Apr 7, 6:21 pm, Russell Keith-Magee  wrote:
> James spoke with me about this decision at the time, and I completely
> agree with and endorse his actions.

So be it then.

> While it is true that wikis contain all sorts of information, often
> unofficial, the naming of the wiki pages in question --
> DjangoSpecifications/Core -- conveyed a *very* strong signal that the
> information contained was official in some capacity. Regardless of the
> merits of the information on that page, the simple fact remains that
> it *isn't* official, and it *wasn't* vetted or edited by anyone in the
> core.

The naming was an unfortunate mistake that dates back two
years-ish when I was trying to advocate supplementing the
mailing list discussions (that tended to be much lengthier
and more diffuse as Django was still much in flux back then)
with specification pages on the wiki (that usually tend to
coalesce to clear, to-the-point documents faster) --
inspired by Python's PEP process. Although I failed horribly
back then, I'm glad that everybody writes them nowadays
without much bravado and high ritual ([1], [2], [3], ...).
That's clearly the best way to do it.

The ill-named location doesn't render the information less
valuable in my opinion. I've referred to the review on
several occasions myself, also, Graham links to that page
from
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
. But, evidently, I may be biased (being the "author").

> If you think there is some valuable information in the wiki pages that
> were deleted, then you need to turn that information into either
> tickets in Trac, or a draft for addition to the official
> documentation. If you think there is some information on that page
> that doesn't fit into the official locations that Django currently
> provides, then we need to have a meta-discussion around the right
> place to house information of that sort.

Although I personally would like to see a wiki section that
collects all the fine technical documents already referred
to above ([1], [2], [3], ...) + unofficial "internals" docs
in the vein of the threading review, I believe no-one will
step up to compile one. So let it be.

Best,
MS

P.S. What about
http://code.djangoproject.com/wiki/CollaborateOnGithub
that I have been maintaining? Should that also be maintained
outside of Django wiki?

[1] http://code.djangoproject.com/wiki/Signing
[2] http://code.djangoproject.com/wiki/CsrfProtection
[3] http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Issues with .only() and Meta.verbose_name{,_plural} inheritance

[Jerome Leclanche]

The following code reproduces an issue I'm getting on prod with
verbose_name. When using .only(), the class changes, and Meta does not
get inherited.

Trac is being even more terrible than usual, I've been trying to file
a bug for the past 15 minutes. I'd love to work on a patch, hopefully
get this fixed before 1.2 as it looks like a minor fix. Any idea?

*-

from django.db.models import Model, fields

class TestModel(Model):
name = fields.CharField(max_length=64)
summary = fields.TextField()

class Meta:
verbose_name = "fooo"

def __unicode__(self):
return self._meta.verbose_name


>>> from testapp.models import TestModel
>>> obj = TestModel(name="bar")
>>> obj.save()
>>> TestModel.objects.filter(pk=1).only("name")
[]



J. Leclanche / Adys

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Threading review wiki page removal

[Russell Keith-Magee]

On Wed, Apr 7, 2010 at 3:37 AM, mrts  wrote:
> On Apr 7, 6:21 pm, Russell Keith-Magee  wrote:
>> James spoke with me about this decision at the time, and I completely
>> agree with and endorse his actions.
>
> So be it then.
>
>> While it is true that wikis contain all sorts of information, often
>> unofficial, the naming of the wiki pages in question --
>> DjangoSpecifications/Core -- conveyed a *very* strong signal that the
>> information contained was official in some capacity. Regardless of the
>> merits of the information on that page, the simple fact remains that
>> it *isn't* official, and it *wasn't* vetted or edited by anyone in the
>> core.
>
> The naming was an unfortunate mistake that dates back two
> years-ish when I was trying to advocate supplementing the
> mailing list discussions (that tended to be much lengthier
> and more diffuse as Django was still much in flux back then)
> with specification pages on the wiki (that usually tend to
> coalesce to clear, to-the-point documents faster) --
> inspired by Python's PEP process. Although I failed horribly
> back then, I'm glad that everybody writes them nowadays
> without much bravado and high ritual ([1], [2], [3], ...).
> That's clearly the best way to do it.
>
> The ill-named location doesn't render the information less
> valuable in my opinion.

The *value* of the information is not in question. The *presentation*
is. If there is valuable information about using Django, we want it to
be in our official documentation. We want it to be edited, proof read,
validated, and incorporated into our official documentation.

Django has very good documentation. We want it to have excellent
documentation. We achieve that goal by having people contribute in a
common way - by submitting patches to our our official documentation -
not by developing independent sources of authority elsewhere on the
djangoprojet.com website.

> I've referred to the review on
> several occasions myself, also, Graham links to that page
> from
> http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
> . But, evidently, I may be biased (being the "author").
>
>> If you think there is some valuable information in the wiki pages that
>> were deleted, then you need to turn that information into either
>> tickets in Trac, or a draft for addition to the official
>> documentation. If you think there is some information on that page
>> that doesn't fit into the official locations that Django currently
>> provides, then we need to have a meta-discussion around the right
>> place to house information of that sort.
>
> Although I personally would like to see a wiki section that
> collects all the fine technical documents already referred
> to above ([1], [2], [3], ...) + unofficial "internals" docs
> in the vein of the threading review, I believe no-one will
> step up to compile one. So let it be.

You're missing my point. We don't want to have an unofficial
documentation section *at all*. If there is a hole in our
documentation, then we want to plug that hole with an official
resource.

[1], [2], and [3] aren't permanent documentation - they're scratch
documents that are (or were) used to develop the design of a feature.
Once the feature is complete, the temporary wiki document should be
replaced with a permanent official documentation page - for example,
[4] is the official analog of [2].

[4] http://docs.djangoproject.com/en/dev/ref/contrib/csrf/

> P.S. What about
> http://code.djangoproject.com/wiki/CollaborateOnGithub
> that I have been maintaining? Should that also be maintained
> outside of Django wiki?

This doesn't concern me as much, for three reasons:

 1) It's not something about the core operation of Django itself -
it's about how to use an external tool to help you contribute to
Django.

 2) There's nothing in the page title that implies that it's an
official resource

 3) There's a big honking "NOT OFFICIAL" at the top of the page.

This is the sort of thing where I think the wiki has value -
unofficial information that is related to the core in some way.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

[GSOC] NoSQL Support for the ORM

[Alex Gaynor]

Non-relational database support for the Django ORM
==

Note:  I am withdrawing my proposal on template compilation.  Another student
has expressed some interest in working on it, and in any event I am now more
interested in working on this project.

About Me


I'm a sophomore computer science student at Rensselaer Polytechnic Institute.
I'm a frequent contributor to Django (including last year's successful multiple
database GSoC project) and other related projects; I'm also a committer on both
`Unladen Swallow `_ and
`PyPy `_.

Background
~~

As the person responsible for large swaths of multiple database support I am
intimately familiar with the architecture of the ORM, the code itself, and the
various concerns that need to be accounted for (pickleability, etc.).

Rationale
~

Non-relational databases tend to support some subset of the operations that are
supported on relational databases, therefore it should be possible to perform
these operations on all databases.  Some people are of the opinion that we
shouldn't bother to support these databases, because they can't perform all
operations, I'm of the opinion that the abstraction is already a little leaky,
we may as well exploit this for a common API where possible, as well as giving
users of these databases the admin and models forms for free.

Method
~~

The ORM architecture currently has a ``QuerySet`` which is backend agnostic, a
``Query`` which is SQL specific, and a ``SQLCompiler`` which is backend
specific (i.e. Oracle vs. MySQL vs. generic).  The plan is to change ``Query``
to be backend agnostic by delaying the creation of structures that are SQL
specific, specifically join/alias data.  Instead of structures like
``self.where``, ``self.join_aliases``, or ``self.select`` all working in terms
of joins and table aliases the composition of a query would be stored in terms
of a tree containing the "raw" filters, as passed to the filter calls, with
things like ``Field.get_prep_value`` called appropriately.  The ``SQLCompiler``
will be responsible for computing the joins for all of these data-structures.

The major complications are operations where ordering matters, for example
``filter()`` and ``annotate()``.  Because the order of these operations matters
it is imperative that the structures continue to maintain the ordered semantics
of these methods.  Another example is that filters across a many valued
relationship have different semantics when they're in the same call to
``filter()`` as opposed to separate calls.  In the current ``Query`` this is
represented by using different table aliases, however because the new structure
doesn't deal in aliases yet all values should be annotated with a table
"counter" indicating that once joins are computed two different values need to
be on the same join.  This is a bit of a leaky abstraction, but that's life.
It should be noted that joins don't have to be explicitly marked as being
different, only the same (i.e. the ``SQLCompiler`` can choose to reuse,
reorder, or do anything else it likes to efficiently generate SQL).

For operations that aren't supported by a backend (i.e. a JOIN on a
non-relational backend, or ``extra`` SQL on non-SQL backends) it is the
backend's responsibility to raise the appropriate exception (or attempt to
emulate it in some way (e.g. some JOINs can be emulated with nested IN
queries)).

Timeline


This timeline is way coarser than I'd like, consider it a work in progress.

 * 2 weeks - update all ``Query`` methods to store data in a backend agnostic
   manner.
 * 4 weeks - update ``SQLCompiler`` to correctly generate SQL from the
   structures, specifically migrate the JOIN generation logic.
 * 2 weeks - begin working on a backend for a non-relational database (probably
   MongoDB)
 * 3 weeks - deal with bugs as they come up, these will mostly be
related to the
   semantics of inserts and updates at a guess.

Deliverables


 * Refactored ORM ``Query`` and ``SQLCompiler`` classes.
 * A working MongoDB backend (to live outside of the core) supporting:
   * Native lookups (MongoDB supports most "basic" lookup types)
   * Creation/update
   * deletion
   * Working forms (should fall out naturally)

Reality
~~~

All applications aren't magically going to start working on database they
weren't designed to work with.  Using a non-relational database requires a
fundamental change of mindset, the point of this is to be able to use the same
API where possible, and get access to things like the admin and forms.

A note on the admin
~~~

The admin's fundamental operations are list, create, update.  Fundamentally
these should fall out, naturally, for all backends that work.  However, there
are some operations that can subtly require more advanced backend
operations.  Specifically, ``list_filter`` a

Re: Issues with .only() and Meta.verbose_name{,_plural} inheritance

[Russell Keith-Magee]

On Wed, Apr 7, 2010 at 4:33 AM, Jerome Leclanche  wrote:
> The following code reproduces an issue I'm getting on prod with
> verbose_name. When using .only(), the class changes, and Meta does not
> get inherited.
>
> Trac is being even more terrible than usual, I've been trying to file
> a bug for the past 15 minutes. I'd love to work on a patch, hopefully
> get this fixed before 1.2 as it looks like a minor fix. Any idea?

On the Trac issue? I can't shed any light on that, especially without
any error messages to suggest what might be going wrong.

On the ORM issue? Yes, this looks like a bug. However, while annoying,
it's not 1.2 critical. It isn't a regression in behavior in trunk, and
it poses no potential for data loss.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Issues with .only() and Meta.verbose_name{,_plural} inheritance

[Richard Laager]

On Tue, 2010-04-06 at 23:33 +0300, Jerome Leclanche wrote:
> The following code reproduces an issue I'm getting on prod with
> verbose_name. When using .only(), the class changes, and Meta does not
> get inherited.
> 
> Trac is being even more terrible than usual, I've been trying to file
> a bug for the past 15 minutes. I'd love to work on a patch, hopefully
> get this fixed before 1.2 as it looks like a minor fix. Any idea?
> 
> *-
> 
> from django.db.models import Model, fields
> 
> class TestModel(Model):
>   name = fields.CharField(max_length=64)
>   summary = fields.TextField()
>   
>   class Meta:
>   verbose_name = "fooo"
>   
>   def __unicode__(self):
>   return self._meta.verbose_name

I ran into this as well. Use this:

def __unicode__(self):
opts = self._meta
while opts.proxy:
opts = opts.proxy_for_model._meta
return opts.verbose_name

Richard


signature.asc
Description: This is a digitally signed message part