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, se
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
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
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 enhancemen
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
+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
"Dja
+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
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
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
> 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
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 subobjec
+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
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
failu
> 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 whil
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
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
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
T
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
>> ---
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 t
+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 Postg
The documentation says django emulates "ON DELETE CASCADE":
http://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects
But it is missing how to emulate ON DELETE SET NULL.
In this thread Kevin Howerton posted an abstract base class to emulate ON
DELETE SET NULL. But this does not
21 matches
Mail list logo
