Re: Decision required: PostgreSQL minimum versions

[Paul McMillan]

+1 for option 2.

Changing 1.2 behavior now seems like a bad idea, and Jacob's arguments
are good.

-Paul

On Jun 9, 10:22 am, Felipe Prenholato  wrote:
> +1 for options 1 and 2.
>
> I think that change for 1.2.x is to close and we probably have some users
> that not want this change now. Set Postgres 8.0 to 1.3 give this users time
> to move.
>
> And, as Jacob said, do retroative changes from this category now isn't a
> good idea.
>
> 2010/6/9 Jacob Kaplan-Moss 
>
>
>
>
>
> > On Wed, Jun 9, 2010 at 6:59 AM, Russell Keith-Magee
> >  wrote:
> > > PostgreSQL 7.4 was released in November 2005, and will be end-of-lifed
> > > (along with PostgreSQL 8.0) in July this year. Our usual yardstick of
> > > slow updates, RHEL4, shipped with PostgreSQL 7.4. RHEL5 shipped with
> > > PostgreSQL 8.1.
>
> > And IIRC RedHat *will* support newer versions of PostgreSQL even on
> > RHEL4. I don't know a single person, even those still on RHEL4, who
> > are using anything under PostgreSQL 8. PostgreSQL 8.1 is easily twice
> > as fast as 7.4; that's usually enough to get folks to upgrade :)
>
> > >  1) Rollback the changeset, and find a PostgreSQL 7.4-compatible way
> > > of solving the problem. Continue to support PostgreSQL 7.4, and
> > > formally document this fact.
>
> > >  2) Add documentation for 1.3 that imposes a PostgreSQL 8.0 minimum;
> > > rollback r13328, wait until the 1.3 branch is forked, and reapply to
> > > that branch. In other words treat #8901 as a feature, rather than a
> > > bugfix, and introduce the Python 8.0 minimum as a new restriction for
> > > 1.3, much in the same way that we dropped support for Python 2.3 in
> > > Django 1.2.
>
> > >  3) Retroactively modify the documentation saying Django 1.2 required
> > > PostgreSQL 8.0 as a minimum. This treats the absence of a documented
> > > minimum required version as a bug, and addresses the bug by picking a
> > > minimum supported version that. r13328 stays as is.
>
> > If we'd thought of it, dropping 7.4 support in 1.2 would have been the
> > right thing to do. However, retroactively doing so now would be abuse
> > of the time machine privileges and I'd like to avoid being grounded.
> > #1's not worth the effort, so that just leaves #2, which sounds about
> > right to me.
>
> > 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 > i...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> --
> Felipe 'chronos' Prenholato.
> Linux User nº 405489
> Home page:http://chronosbox.org/blog
> Twitter:http://twitter.com/chronossc

-- 
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.

ANN: Sprint June 19-20 in Los Angeles (Santa Monica)

[Jacob Kaplan-Moss]

Hey folks --

Mahalo will be hosting a Django sprint at their offices in Santa
Monica June 19th and 20th, and they've been awesome enough to help me
get out to Cali for it.

So I'd like to invite y'all to join me, either in person at Mahalo HQ or online.

I'm trying something a bit different this time: this sprint will have
a suggested theme, which is performance and scalability. Of course,
like all sprints, everyone is free to work on whatever they'd like,
but I'll be encouraging folks to work on performance-related issues --
optimization, scaling, benchmarking, etc.

If you want more info, check out
http://code.djangoproject.com/wiki/Sprint201006LA. If you'll be
attending, please be sure to RSVP by adding your name to the attendee
list on the wiki.

Big thanks to Mahalo for their support!

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: Admin patches

[Alex Gaynor]

On Wed, Jun 9, 2010 at 3:56 PM, Jeremy Dunck  wrote:
> On Wed, Jun 9, 2010 at 3:52 PM, Simon Meers  wrote:
> ...
>> Did you also know you can run any desired subset of tests? E.g.:
>>    ./runtests.py --settings=test_sqlite admin_inlines admin_views
>>    --
>>    Ran 145 tests in 29.500s
>
> Thanks for pointing this out, Simon.  I thin it could be clearer in
> the contributing/testing docs.
>
> Running a subset while working up a patch can help speed things along
> quite a bit, but do take care to run the whole suite before pushing
> the patch -- the committer will have to do this anyway, and a failure
> missed this way will just delay inclusion.
>
> --
> 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.
>
>

FWIW at least on my system the test time has come down dramatically
lately, we're back down to under 3 minutes on SQLite, so that should
help everyone in testing and contributing.

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: Admin patches

[Jeremy Dunck]

On Wed, Jun 9, 2010 at 3:52 PM, Simon Meers  wrote:
...
> Did you also know you can run any desired subset of tests? E.g.:
>    ./runtests.py --settings=test_sqlite admin_inlines admin_views
>    --
>    Ran 145 tests in 29.500s

Thanks for pointing this out, Simon.  I thin it could be clearer in
the contributing/testing docs.

Running a subset while working up a patch can help speed things along
quite a bit, but do take care to run the whole suite before pushing
the patch -- the committer will have to do this anyway, and a failure
missed this way will just delay inclusion.

-- 
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: Admin patches

[Simon Meers]

Hi Sebastian,

> Btw, running the test suite with mysql takes forever.
> If you know the reason please tell me. However i was able to run the
> test suite on a plain django 1.2.1 installation with sqlite, but got 11
> failures and 37 errors ...

Have you read [1]? Do you still get errors if you run:
./runtests.py --settings=test_sqlite
from the tests/ directory?

Did you also know you can run any desired subset of tests? E.g.:
./runtests.py --settings=test_sqlite admin_inlines admin_views
--
Ran 145 tests in 29.500s

Simon

[1] 
http://docs.djangoproject.com/en/dev/internals/contributing/#running-the-unit-tests

-- 
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.

javascript jsi18n

[DoctorArnar]

There are a few things wrong with the javascript for jsi18n.

1. Global variables, there are too many of them and very likely that
someone would like to use the variable "format" and "catalog witch are
both global.
2. The gettext funcion should be more performance enhanced, like use
=== instead of ==
3. Array you shouldn't be used as an associative array, use Object
instead.


Links:
1 .http://yuiblog.com/blog/2006/06/01/global-domination/
2. http://javascript.crockford.com/ ( well he talks about is
somewhere )
3. 
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Array
| 
http://andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/

-- 
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: Django Related-Object Links in Admin

[Simon Meers]

> The demo screenshots you provide certainly look good to me; I haven't
> done a full teardown on the patch, but a from a quick glance it
> certainly looks promising.

Thanks for your response Russ.

>  * Why allow edit links on a readonly field? This seems a little
> redundant to me?

Because whilst the field on that model might be read-only, the related
object itself is not necessarily. In fact in most cases I've found
that this is the case.

>  * On the edit link for ForeignKey (localhost:8000 in your example),
> I'd be inclined to stick to just "edit", not "edit " -- that
> seems more consistent with the other edit links you have provided.

But then if you select a different object, "edit" looks like it refers
to the selected one instead of the original. I could have used
JavaScript here to select the dynamically chosen object, but in the
absence of a popup link this would be pointless -- you choose a
different ForeignKey value, then leave the page to edit it thinking
you've saved the value...

>  * I take it that the widget edit links carry through to inlines?
> i.e., if i have a foreign key pulldown in an inline, I will get the
> edit link?

Yes.

>  * How does performance degrade when JavaScript is not available? Do
> the links exist at all, or do they become dangling links to the wrong
> object?

Solid as a rock; does not use JavaScript.

>  * In the case of raw-id fields and inlines, is there any reason why
> the edit link is separate text, rather than the object name itself
> being the link? (ie., rather than "John smith ", why
> not just ""?

Yes; because you're already editing John smith, but if you want to
edit him separately you can go elsewhere to do so with a (probably
more detailed) dedicated form.

>  * Permissions - from my initial inspection, it isn't obvious to me
> that you are honoring (and/or testing that you are honoring)
> permissions. If I don't have permission to edit an object, I shouldn't
> get an edit link. Given the addition in 1.2 of object-level
> permissions, this means permissions need to be per-object. Have I
> missed something in my hasty patch read?

Correct; no permissions checking is performed at present. In some
places checking would be almost impossible given the current code
architecture, so I had hoped to avoid it if possible. This was one of
the main points I wanted feedback on.

Simon

-- 
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: Admin patches

[Sebastian Noack]

Hi Jacob,

thanks for your feedback, I have respond to your comments. I am going
to add tests now. Btw, running the test suite with mysql takes forever.
If you know the reason please tell me. However i was able to run the
test suite on a plain django 1.2.1 installation with sqlite, but got 11
failures and 37 errors [1]. Do I have configured my test environment
wrong? Here is my settings.py [1].

[1] http://pastebin.org/321014
[2] http://pastebin.org/321027


Regards
Sebastian NoacK


signature.asc
Description: PGP signature

Re: Decision required: PostgreSQL minimum versions

[Felipe Prenholato]

+1 for options 1 and 2.

I think that change for 1.2.x is to close and we probably have some users
that not want this change now. Set Postgres 8.0 to 1.3 give this users time
to move.

And, as Jacob said, do retroative changes from this category now isn't a
good idea.


2010/6/9 Jacob Kaplan-Moss 

> On Wed, Jun 9, 2010 at 6:59 AM, Russell Keith-Magee
>  wrote:
> > PostgreSQL 7.4 was released in November 2005, and will be end-of-lifed
> > (along with PostgreSQL 8.0) in July this year. Our usual yardstick of
> > slow updates, RHEL4, shipped with PostgreSQL 7.4. RHEL5 shipped with
> > PostgreSQL 8.1.
>
> And IIRC RedHat *will* support newer versions of PostgreSQL even on
> RHEL4. I don't know a single person, even those still on RHEL4, who
> are using anything under PostgreSQL 8. PostgreSQL 8.1 is easily twice
> as fast as 7.4; that's usually enough to get folks to upgrade :)
>
> >  1) Rollback the changeset, and find a PostgreSQL 7.4-compatible way
> > of solving the problem. Continue to support PostgreSQL 7.4, and
> > formally document this fact.
> >
> >  2) Add documentation for 1.3 that imposes a PostgreSQL 8.0 minimum;
> > rollback r13328, wait until the 1.3 branch is forked, and reapply to
> > that branch. In other words treat #8901 as a feature, rather than a
> > bugfix, and introduce the Python 8.0 minimum as a new restriction for
> > 1.3, much in the same way that we dropped support for Python 2.3 in
> > Django 1.2.
> >
> >  3) Retroactively modify the documentation saying Django 1.2 required
> > PostgreSQL 8.0 as a minimum. This treats the absence of a documented
> > minimum required version as a bug, and addresses the bug by picking a
> > minimum supported version that. r13328 stays as is.
>
> If we'd thought of it, dropping 7.4 support in 1.2 would have been the
> right thing to do. However, retroactively doing so now would be abuse
> of the time machine privileges and I'd like to avoid being grounded.
> #1's not worth the effort, so that just leaves #2, which sounds about
> right to me.
>
> 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.
>
>


-- 
Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://chronosbox.org/blog
Twitter: http://twitter.com/chronossc

-- 
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.

InlineAdminFormSet in django.contrib.admin.helpers

[shaunc]

I'm wondering why the "model_admin" for an inline formset is the
parent model_admin, and not the inline model admin? Given that the
inline admin is passed as "inline", and stored as "opts" in the in
InlineAdminFormSet, I'm wondering if "opts" needs to be passed in the
"model_admin" slot to subobjects. After all, these objects use the
model_admin to look up objects, and yet they are using the form from
the inline. This causes problems -- e.g. -- for
AdminReadonlyField.contents, when it tries to look up contents for the
field of the subobject but uses the model admin of the parent object.

I almost immediately opened a ticket on this, but since its so
systematic, I'm wondering if there is some rationale for the way it is
done?

Thanks,

-- Shaun Cutts

-- 
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: Decision required: PostgreSQL minimum versions

[Matt Hoskins]

> If we'd thought of it, dropping 7.4 support in 1.2 would have been the
> right thing to do. However, retroactively doing so now would be abuse
> of the time machine privileges and I'd like to avoid being grounded.
> #1's not worth the effort, so that just leaves #2, which sounds about
> right to me.

Django 1.2 doesn't say which versions of postgresql it supports at the
moment - that may well be just be semantics tho' as I guess anyone
who's tested it will have found it works so far :). I guess people who
are going to hit the bug in #8901 (which may be very few) when
changing from 1.1 to 1.2 will discover the problem in testing so can
hold off on migrating (or apply the patch manually), whereas people
using postgresql 7.4 may already be on version 1.2 and breaking it
working on 7.4 in a point release on 1.2.1 would be less acceptable as
they would already have moved to 1.2 and couldn't then get security
updates for 1.2 [1]

[1] Note that on django-users I did mention that it's possible to
create the function in postgresql 7.x that exists in 8 which the fix
for #8901 relies on, so they have a work around too.

-- 
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: Decision required: PostgreSQL minimum versions

[Jacob Kaplan-Moss]

On Wed, Jun 9, 2010 at 6:59 AM, Russell Keith-Magee
 wrote:
> PostgreSQL 7.4 was released in November 2005, and will be end-of-lifed
> (along with PostgreSQL 8.0) in July this year. Our usual yardstick of
> slow updates, RHEL4, shipped with PostgreSQL 7.4. RHEL5 shipped with
> PostgreSQL 8.1.

And IIRC RedHat *will* support newer versions of PostgreSQL even on
RHEL4. I don't know a single person, even those still on RHEL4, who
are using anything under PostgreSQL 8. PostgreSQL 8.1 is easily twice
as fast as 7.4; that's usually enough to get folks to upgrade :)

>  1) Rollback the changeset, and find a PostgreSQL 7.4-compatible way
> of solving the problem. Continue to support PostgreSQL 7.4, and
> formally document this fact.
>
>  2) Add documentation for 1.3 that imposes a PostgreSQL 8.0 minimum;
> rollback r13328, wait until the 1.3 branch is forked, and reapply to
> that branch. In other words treat #8901 as a feature, rather than a
> bugfix, and introduce the Python 8.0 minimum as a new restriction for
> 1.3, much in the same way that we dropped support for Python 2.3 in
> Django 1.2.
>
>  3) Retroactively modify the documentation saying Django 1.2 required
> PostgreSQL 8.0 as a minimum. This treats the absence of a documented
> minimum required version as a bug, and addresses the bug by picking a
> minimum supported version that. r13328 stays as is.

If we'd thought of it, dropping 7.4 support in 1.2 would have been the
right thing to do. However, retroactively doing so now would be abuse
of the time machine privileges and I'd like to avoid being grounded.
#1's not worth the effort, so that just leaves #2, which sounds about
right to me.

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: Decision required: PostgreSQL minimum versions

[Matt Hoskins]

I have already given some of my thoughts on django-users and on the
ticket for 8901... Andrew Godwin's reasoning above feels sound to me,
so considering that and that 1.1 would still work for postgres 7.4
users (plus my desire to see the bug in 8901 fixed sooner rather than
later as it does affect me, although I can patch django myself if I
have to wait to 1.3 so that's only minor) I'd say...

+1 on option 3
+0 on option 2
-1 on option 1

I think if the fix for 8901 isn't put into 1.2 (i.e. option 2 is
chosen) it might be worth adding a note into release notes  for 1.2
about it being a known issue just because the change in m2m saves
means that users (like me) who have a combination of a longish model
name and a longish m2m field name will find things break on upgrading
from 1.1 to 1.2 so you'd want to warn them off doing so!

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.

Re: Decision required: PostgreSQL minimum versions

[Harro]

+1 on option 3.

Oldest postgresql we have is 8.2.
I pity the fool who didn't upgrade !


On Jun 9, 2:38 pm, Antoni Aloy  wrote:
> +1 on Drop 7.4 PostgreSQL support. Postgressql 8.x series has lots of
> performance and utility features and it would be a pity to remain in
> 7.4.
>
> --
> Antoni Aloy López
> Blog:http://trespams.com
> Site:http://apsl.net

-- 
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: Decision required: PostgreSQL minimum versions

[Antoni Aloy]

+1 on Drop 7.4 PostgreSQL support. Postgressql 8.x series has lots of
performance and utility features and it would be a pity to remain in
7.4.

-- 
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

-- 
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: Beating on an old issue; counter intuitive cascade deletes on foreign keys

[Russell Keith-Magee]

On Wed, Jun 9, 2010 at 3:53 AM, Peter Bengtsson  wrote:
> On 8 June 2010 13:09, Jeremy Dunck  wrote:
>> On Tue, Jun 8, 2010 at 7:30 AM, Peter Bengtsson  wrote:
>>> I've now had to learn this the hard way by having real live data
>>> deleted from my database on two production projects and it pisses me
>>> off big time every time.
>>>
>>> I can accept that NOT nullable foreign relations cascade the delete
>>> but not if they have null=True on them. Example:
>>
>> Actually, this looks to be fixed in 1.2.  What version are you
>> running?  Closed ticket (with test cases) here:
>> http://code.djangoproject.com/ticket/9308
>>
> I'm running Django 1.2.1 so perhaps it's not fixed.
> Sigh. I have to make a test case to prove it.

Looking at Trac, #9308 was fixed in r10822, so it should be fixed in
1.1, and it was ported back to 1.0.X as well.

We pretty clearly document that our deletion scheme emulates "ON
DELETE CASCADE"; if you can provide evidence to the contrary, please
open a ticket.

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: Django Related-Object Links in Admin

[Russell Keith-Magee]

On Wed, Jun 9, 2010 at 5:25 AM, Simon Meers  wrote:
> On 25 May 2010 07:50, Simon Meers  wrote:
>>
>> I've uploaded some screenshots [1] of the new patch for #13163 [2] and
>> #13165 [3] in action, to allow people to see the affect without
>> necessarily applying the changes.
>>
>> These enhancements have *vastly* improved the navigability of the
>> admin interface between related objects.
>>
>> Please have a look and let me know if you have concerns or suggestions
>> for improvement. The design decisions are documented in the tickets.
>>
>> [1] http://share.simonmeers.com/django_related_changelinks/
>> [2] http://code.djangoproject.com/ticket/13163
>> [3] http://code.djangoproject.com/ticket/13165
>
>
> I'm guessing DjangoCon.eu week wasn't the ideal time to send this.
> Loads of people did check the screenshots out though. Anyone have
> concerns or suggestions?

The demo screenshots you provide certainly look good to me; I haven't
done a full teardown on the patch, but a from a quick glance it
certainly looks promising.

A couple of quick questions:

 * Why allow edit links on a readonly field? This seems a little
redundant to me?

 * On the edit link for ForeignKey (localhost:8000 in your example),
I'd be inclined to stick to just "edit", not "edit " -- that
seems more consistent with the other edit links you have provided.

 * I take it that the widget edit links carry through to inlines?
i.e., if i have a foreign key pulldown in an inline, I will get the
edit link?

 * How does performance degrade when JavaScript is not available? Do
the links exist at all, or do they become dangling links to the wrong
object?

 * In the case of raw-id fields and inlines, is there any reason why
the edit link is separate text, rather than the object name itself
being the link? (ie., rather than "John smith ", why
not just ""?

 * Permissions - from my initial inspection, it isn't obvious to me
that you are honoring (and/or testing that you are honoring)
permissions. If I don't have permission to edit an object, I shouldn't
get an edit link. Given the addition in 1.2 of object-level
permissions, this means permissions need to be per-object. Have I
missed something in my hasty patch read?

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: Decision required: PostgreSQL minimum versions

[Andrew Godwin]

On 09/06/2010 12:59, Russell Keith-Magee wrote:

Hi all,

While we support PostgreSQL, our documentation doesn't actually
specify a minimum supported version. We have a couple of features that
are no-ops for versions prior to 8.2 (savepoints and database
autocommit), but we don't actually document a minimum required
version.

We have a specified minimum of SQLite 3.3.6 and Oracle 9i (10g for
certain features); we have a vague suggestion that MySQL 4.1 is the
minimum supported version (but we don't rule out support for 3.23 and
4.0); but what is our policy with PostgreSQL? Do we support PostgreSQL
7.4?

PostgreSQL 7.4 was released in November 2005, and will be end-of-lifed
(along with PostgreSQL 8.0) in July this year. Our usual yardstick of
slow updates, RHEL4, shipped with PostgreSQL 7.4. RHEL5 shipped with
PostgreSQL 8.1.

Why am I asking? Because of r13328. In that changeset, I added a fix
for #8901 using a database function that is available in PostgreSQL
8.0, but not in PostgreSQL 7.4.

So - I'm looking for community opinion on how to deal with this. I can
see (at least) three options:

  1) Rollback the changeset, and find a PostgreSQL 7.4-compatible way
of solving the problem. Continue to support PostgreSQL 7.4, and
formally document this fact.

  2) Add documentation for 1.3 that imposes a PostgreSQL 8.0 minimum;
rollback r13328, wait until the 1.3 branch is forked, and reapply to
that branch. In other words treat #8901 as a feature, rather than a
bugfix, and introduce the Python 8.0 minimum as a new restriction for
1.3, much in the same way that we dropped support for Python 2.3 in
Django 1.2.

  3) Retroactively modify the documentation saying Django 1.2 required
PostgreSQL 8.0 as a minimum. This treats the absence of a documented
minimum required version as a bug, and addresses the bug by picking a
minimum supported version that. r13328 stays as is.

Our general policy for deprecating old dependencies is something we
need to have a bigger discussion about -- especially as it relates to
Python itself -- but this PostgreSQL issue is immediate and pressing.
I certainly hope that any reasoning behind the decision we make for
PostgreSQL could be generalized to answer the same question for any
other dependency.

Opinions?

Yours,
Russ Magee %-)
   


So, my opnion on this is that we should drop 7.4 support, but I'm not 
sure if it should be done in 1.3 or 1.2.


Firstly, from what I can find 
(http://www.postgresql.org/docs/7.4/static/release-7-4.html), PostgreSQL 
7.4 was released in 2003, not 2005, which puts it in the same 
depreciation area as Python 2.3 (also 2003). RHEL4 itself was released 
in 2005.


Given than 1.2 has dropped support for Python 2.3, and thus already 
won't work on RHEL4, I see no real reason we should keep supporting 7.4, 
especially if it's being EOL'd soon.


As for whether to apply the fix to 1.2 or 1.3, 1.3 seems a safer option, 
but if there's no outcry from 7.4 users I'd be tempted to document 1.2 
as being PostgreSQL 8.0 and up (after all, best to bundle one 
RHEL4-breaking change with another). Given that it's a database, though, 
people might want to keep running their old RHEL4 database boxes and 
only upgrade their frontend servers, so it's definitely not easy to choose.


Still, I think option 1 is just going to hold Django back - there's a 
few things they fixed in 8.0, most notably (for me) the implementation 
of information_schema, which any PostgreSQL schema-altering backend is 
going to want.


Andrew

--
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.

Decision required: PostgreSQL minimum versions

[Russell Keith-Magee]

Hi all,

While we support PostgreSQL, our documentation doesn't actually
specify a minimum supported version. We have a couple of features that
are no-ops for versions prior to 8.2 (savepoints and database
autocommit), but we don't actually document a minimum required
version.

We have a specified minimum of SQLite 3.3.6 and Oracle 9i (10g for
certain features); we have a vague suggestion that MySQL 4.1 is the
minimum supported version (but we don't rule out support for 3.23 and
4.0); but what is our policy with PostgreSQL? Do we support PostgreSQL
7.4?

PostgreSQL 7.4 was released in November 2005, and will be end-of-lifed
(along with PostgreSQL 8.0) in July this year. Our usual yardstick of
slow updates, RHEL4, shipped with PostgreSQL 7.4. RHEL5 shipped with
PostgreSQL 8.1.

Why am I asking? Because of r13328. In that changeset, I added a fix
for #8901 using a database function that is available in PostgreSQL
8.0, but not in PostgreSQL 7.4.

So - I'm looking for community opinion on how to deal with this. I can
see (at least) three options:

 1) Rollback the changeset, and find a PostgreSQL 7.4-compatible way
of solving the problem. Continue to support PostgreSQL 7.4, and
formally document this fact.

 2) Add documentation for 1.3 that imposes a PostgreSQL 8.0 minimum;
rollback r13328, wait until the 1.3 branch is forked, and reapply to
that branch. In other words treat #8901 as a feature, rather than a
bugfix, and introduce the Python 8.0 minimum as a new restriction for
1.3, much in the same way that we dropped support for Python 2.3 in
Django 1.2.

 3) Retroactively modify the documentation saying Django 1.2 required
PostgreSQL 8.0 as a minimum. This treats the absence of a documented
minimum required version as a bug, and addresses the bug by picking a
minimum supported version that. r13328 stays as is.

Our general policy for deprecating old dependencies is something we
need to have a bigger discussion about -- especially as it relates to
Python itself -- but this PostgreSQL issue is immediate and pressing.
I certainly hope that any reasoning behind the decision we make for
PostgreSQL could be generalized to answer the same question for any
other dependency.

Opinions?

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: Admin patches

[batiste]

Hi,

There is also this small fix that need feedback. There is a patch but
no doc (it's more a bug fix than a new feature)

http://code.djangoproject.com/ticket/12241

-- 
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.