Re: [Fwd: Documentation: Google-foo lost]

[Steve Holden]

Don Spaulding wrote:
>
>
> On Tue, Sep 16, 2008 at 2:20 PM, Don Spaulding
> <[EMAIL PROTECTED] > wrote:
>
>
> Hope it's useful!
>
>
>
> and of course it isn't.  I forgot my lambdas.  Doh!
>
That's a great start. I noticed that many Google links are to fragments,
and wondered if we could do some sort of recognition on them. It turned
out to be interesting, as I was hadn't realised the documentation
doesn't implement fragment references in the expected way.

I pulled down the current documentation and the 0.96 stuff with
websucker - I think it broke before it got quite all the old stuff, but
the majority is present. The work I have done would really best be done
on the final version of the pre-1.0 documentation before it was
converted to the new organization, but I couldn't find that. So far I've
only looked at the section headings, which can be located easily as .

There are 119 sections like
general-questions
genericsitemap
specialities-of-django-translation
definitive-urls
creating-models
installation-questions
template-inheritance
overriding-default-model-methods
less-code and
serialization-formats

which don't seem to appear (as sections) in the new documentation. So
it's goodbye to them unless they appear as other structures in the new
documentation.

There are apparently 678 newly-minted sections like
module-django.forms.fields
using-generic-relations-as-an-inline
inherited-models
onetoonefield
extra-methods-on-managers-when-used-in-a-foreignkey-context
post-delete
inlinemodeladmin-objects
module-django.test
module-django.http and
the-file-object

that never appeared (as sections) in the old documentation, so we don't
need to worry about them unless they appeared as tags on some other type
of object.

The *good* news is that there appear to be 789 sections that can be
redirected (hopefully with 301s, so Google and pals will pick up the new
locations), of which a few examples are:

Tag requesting-features
was: ./contributing/index.html
now: dev/internals/contributing/index.html
Tag font-sizes
was: ./admin_css/index.html
now: dev/obsolete/admin-css/index.html
Tag relationships
was: ./model-api/index.html
now: dev/topics/db/models/index.html
Tag phone2numeric
was: ./templates/index.html
now: dev/ref/templates/builtins/index.html
Tag pprint
was: ./templates/index.html
now: dev/ref/templates/builtins/index.html
Tag restarting-the-spawned-server
was: ./fastcgi/index.html
now: dev/howto/deployment/fastcgi/index.html
Tag basics
was: ./templates_python/index.html
now: dev/ref/templates/api/index.html
Tag how-to-add-change-and-delete-redirects
was: ./redirects/index.html
now: dev/ref/contrib/redirects/index.html
Tag seeing-which-settings-you-ve-changed
was: ./settings/index.html
now: dev/topics/settings/index.html
Tag custom-default-settings
was: ./settings/index.html
now: dev/topics/settings/index.html

Sorry that the old and new references aren't strictly comparable: this
has been a spare time project in a rather busy week. I'm sure it's
fairly obvious where they can be found.

The question is: is it worth continuing this web-scraping and analysis
and potentially extending it to other reference mechanisms I am unaware
of? I don't know whether the current redirection will eventually cause
the web search engines to throw away the old references, but it would be
nice to be able to move them forward if possible.

regards
 Steve




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

Re: Template inheritance and {% include %} tags

[Simon Willison]

On Sep 18, 11:58 pm, SmileyChris <[EMAIL PROTECTED]> wrote:
> I think you missed the point, Simon.
>
> Michael isn't talking about self-referencing extending, he's talking
> about blocks in statically included templates ({% include "bit.htm"
> %}).

Ah yes, sorry - misunderstood the original e-mail.

Cheers,

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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: django.template refactoring (#7806)

[Vinay Sajip]

On Sep 17, 11:52 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-09-17 at 14:42 +0100, Ben Ford wrote:
> > I take it that most are aware of:
>
> >http://lucumr.pocoo.org/cogitations/2008/09/16/why-jinja-is-not-djang...
>
> > It seems like a very well thought out and thorough write up.
>
> Um .. welll. :-(
>
> Parts of it are very well thought out and if it had been a post on "how
> Jinja works" it would have been excellent. Other parts are completely
> unconstrained by facts or acknowledgement that Django's standard
> templates and Jinja's ones have different goals (which is important,
> since this isn't an apples to apples comparison at all).

There are philosophical differences between Django and Jinja
templating about how much power there should be in the templating
engine. Django's philsophy is to keep the power to the minimum
required - "templates are not programs" - and I think we all
understand this, but apart from that point, can you [or one of the
other core devs] be more specific about what you think these different
goals are?

>
> The good news is that, as far as I can see, all the actual bugs he notes
> are already in tickets. I went through and checked quickly yesterday and
> found all but one, which I'm pretty sure is in there, so I'll look again
> today.
>
> Whilst reading that, keep in mind that Armin apparently misunderstands
> (or possibly just omits to clearly state) what a template object
> instance is in Django. It's a state machine for rendering templates and
> includes the current state as well as the transitions. This isn't an
> invalid or particularly novel approach to executing a domain specific
> language. In fact, it makes a lot of sense if you want to write
> self-contained node-based state instances. Jinja and Django templates
> have different compilation strategies and return different types of
> objects and the difference is a vital distinction in any discussion of
> appropriate usage.

I don't think that template users care about the internals as much as
they care about correct behaviour, including in a threaded
environment.

> The blog post appears to imply that it would be
> natural for any random data structure to be used as a global variable
> (by extrapolation, since he doesn't establish that a Template instance
> -- not a class, the instance of a compiled template -- is special in any
> sense, so it must be somehow "normal") and that those structures will
> work beautifully when multiple threads cause its internal state to be
> modified.
>
> This has two problems: (1) it's pretty much false by default (Python !=
> Haskell, Erlang, etc and mutable objects are very normal in Python), and
> (2) it would imply that using lots of globals to store stuff in
> multi-threaded programs is a good idea that people should be doing more
> often.
>
> There's a name for that sort of programming style and it's not
> "Excellent, Maintainable Code". :-)
>
> Using the same logic, Python is not thread-safe at all and shouldn't be
> used, since lists, dictionaries, sets, and pretty much any random
> instance of a class object contain state in the instance that will
> change upon use. Tuples and strings are specially noted to be immutable
> and so are usable in those situations without extra locking, but they're
> special-cases, not the norm, in a pass-by-reference language. Using
> module-level globals sparingly is something we certainly encourage.

I'm not sure how relevant these references to Haskell, Erlang etc.
are. Python, like most other languages, does not guarantee intrinsic
thread safety of its data structures, nor do we expect this. Armin's
point relates to *shared* data across threads, viz. the templates
themselves. When concurrent requests are handled by different threads,
they create separate instances of instrinsically unsafe data
structures, e.g. context and response objects, but as these are not
shared among threads, we don't care that they're not thread-safe
implementations. However, the templates *are* shared, and so they have
a responsibility not to store state in themselves, especially as the
context is there for precisely that purpose. Otherwise, when two
concurrent requests invoke the same template containing a cycle tag,
the cycle tag will not perform properly because the different threads
trample over each other's state. This is, it seems to me, quite
different to needing to set the cycle tag to a known state at the
start of template execution.

> Fortunately, this isn't a real issue, since there's nowhere that we
> suggest the assumption of immutability would be valid (and, really, a
> decent programmer is going to know that any arbitrary data structures
> have the same behaviour unless it's noted as immutable; minimal
> experience says that making assumptions contrary to that always leads to
> trouble). You create the template object as part of a view and render it
> and things are (mostly -- see next para) fine. There's no real need to
> put t

Re: compressed fixture support

[Bas van Oostveen]

I agree with Russ Magee's feeling.

For compression you should just use pipes, you already pipe the output
to a file, you should also pipe it through a compress app.

An -c,--compress option does not make any sense without an accompanying
-o,--output-file option as well.

Though i'm +1 on having transparent support for gzip and bzip2 in
commands where we actually specify the filename. ( ./manage.py loaddata
somefile.json.gz )

And would be as easy to implement, the possible usecases i've got is
with a big fixture of a organism/protein database. This can be
compressed very well and is only applied one, so no need to keep a 50+
MB fixture around (and in version control) when it can be compressed in
a few mb with gzip.

Anyways sorry to bump this thread ;)

On Sat, 2008-09-13 at 19:43 +0800, Russell Keith-Magee wrote:
> On Sat, Sep 13, 2008 at 1:35 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> >
> > I'd like to add support for fixture load/dump to deal with compressed
> > (gzip) files transparently.
> 
> Something like #4924, perhaps? :-)
> 
> I'm not completely sold on the --compress option to dumpdata - there
> are many options for compression other than gz, and you can use shell
> pipes to compress the output of dumpdata using whatever scheme you
> desire.
> 
> However, loading compressed fixtures is a reasonable suggestion
> (although, like Jacob, I don't have much need for them myself).
> 
> 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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: overriding auth.User model

[HenrikV]

Problem solved. The patch works just fine, it is a question of being
careful about imports. Hence it is just a documentation issue.

I will get some documentation done asap. Tweaked the auth tests as
well.

On Sep 17, 6:19 pm, HenrikV <[EMAIL PROTECTED]> wrote:
> Ticket 3011 proposes how to allow overriding the User model. I am
> working on an improved patch that,
>
> * Supports ForeignKey("auth.User") and
> ForeignKey(django.admin.auth.models.User)
> * By default has the same database schema as before the patch
> * Allows an overridden UserAdmin if the User model is.
> * Can serve as a resonable pattern for making override-able db models.
>
> My basic examples seem to work fine. Tests pass and the site runs with
> and without overriding the table.
>
> On my own site things don't quite seem to work. For some reason Django
> thinks that the Groups and Permissions m2m have already been defined
> so related_name appear to be defined twice. I'm pretty sure they are
> not though, so it must me something in the way that I have changed
> things.
>
> Could someone please take a look at my patch or give me some hints on
> how m2m relates to model loading.
>
> http://code.djangoproject.com/attachment/ticket/3011/3011.7.diff
>
> Thanks
>
> P.S. I am personally interested in this because I need to be able to
> replicate the user table, so I have to change the nature of the
> primary key.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: django.template refactoring (#7806)

[Andreas]

What really annoys me is all the talk about how important it is that
its designed for non-programmers but if i recall corectly jacob said
on djangocon that they never aimed for making django a general purpose
webframework, they just made something that fit their needs. With that
said, how many django projects actually involves "template designers"?
Such a job position doesnt exists here in sweden. I bet my five cents
that in most cases the programmer also makes the templates with
semantic html, and the css and the js. Most developers today has
competence that spans all over these areas. So shouldnt we make
something that fit our needs instead of making something for someone
else? Else id like to see some "template designers" in this
discussion.

(Of course Its loose coupled and i can use anything i want, which i
actually do)

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

Nested Inlines in admin!!

[John]

Hi,

I was wondering if nested inlines' will be supported in the admin in
any post 1.0 release. I remember seeing it mentioned in the road map
for the 1.0 release but I guess it was dropped due to time issues.

Thanks!

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

Re: Nested Inlines in admin!!

[Karen Tracey]

On Fri, Sep 19, 2008 at 9:42 AM, John <[EMAIL PROTECTED]> wrote:

>
> Hi,
>
> I was wondering if nested inlines' will be supported in the admin in
> any post 1.0 release. I remember seeing it mentioned in the road map
> for the 1.0 release but I guess it was dropped due to time issues.
>
>
The topic was discussed quite recently on this list:

http://groups.google.com/group/django-developers/browse_thread/thread/7912f4871d23f985/60e33cf2fb8c4e33?


Karen

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

admin doesn't allow more than one null fk where unique=True

[smcoll]

Take this model as an example:

-
from django.db import models
from django.contrib.auth.models import User

class Contact(models.Model):
user = models.ForeignKey(User, unique=True, null=True, blank=True)
-

No more than one Contact can be saved with a Null fk on 'user',
because it considers the "Null" option a unique relation, i guess.
That seems like a big bug, unless i misunderstand the use of
'unique=True'.  It seems to me that 'unique=True' should prevent
multiple fk's to one model instance, but not disallow multiple null
fk's.  Am i right or wrong?

See ticket #9062
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: admin doesn't allow more than one null fk where unique=True

[Karen Tracey]

On Fri, Sep 19, 2008 at 10:51 AM, smcoll <[EMAIL PROTECTED]> wrote:

>
> Take this model as an example:
>
> -
> from django.db import models
> from django.contrib.auth.models import User
>
> class Contact(models.Model):
>user = models.ForeignKey(User, unique=True, null=True, blank=True)
> -
>
> No more than one Contact can be saved with a Null fk on 'user',
> because it considers the "Null" option a unique relation, i guess.
> That seems like a big bug, unless i misunderstand the use of
> 'unique=True'.  It seems to me that 'unique=True' should prevent
> multiple fk's to one model instance, but not disallow multiple null
> fk's.  Am i right or wrong?
>
> See ticket #9062
>

Yes, I believe it's a bug since most of the underlying DB setups allow
multiple nulls.  #9062 actually looks to me like a duplicate of an earlier
bug reporting essentially the same thing, so I just closed it as that. This
is code (I believe) that was added fairly late in the game once general
model validation had to be pushed to post-1.0.  As such I am not sure
whether it is worth fixing in the current code or if it would make more
sense to focus efforts on getting the general model validation done and into
the code base.  Perhaps someone close to model validation would have an
opinion on that?

Karen

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

Re: RFC: django.template refactoring (#7806)

[Jacob Kaplan-Moss]

On Fri, Sep 19, 2008 at 4:15 AM, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> There are philosophical differences between Django and Jinja
> templating about how much power there should be in the templating
> engine. Django's philsophy is to keep the power to the minimum
> required - "templates are not programs" - and I think we all
> understand this, but apart from that point, can you [or one of the
> other core devs] be more specific about what you think these different
> goals are?

http://docs.djangoproject.com/en/dev/misc/design-philosophies/#template-system

In particular:

"""
The goal is not to invent a programming language. The goal is to offer
just enough programming-esque functionality, such as branching and
looping, that is essential for making presentation-related decisions.

The Django template system recognizes that templates are most often
written by designers, not programmers, and therefore should not assume
Python knowledge.
"""

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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: compressed fixture support

[Russell Keith-Magee]

On Fri, Sep 19, 2008 at 6:05 PM, Bas van Oostveen <[EMAIL PROTECTED]> wrote:
>
> And would be as easy to implement, the possible usecases i've got is
> with a big fixture of a organism/protein database. This can be
> compressed very well and is only applied one, so no need to keep a 50+
> MB fixture around (and in version control) when it can be compressed in
> a few mb with gzip.
>
> Anyways sorry to bump this thread ;)

Bump away. However, nothing is going to happen until someone does some
work on #4924 :-)

The last time I looked at the patch on that ticket, it wasn't miles
away from being ready for trunk. The basic implementation was sound -
it just needed to be updated, slightly improved to include zip as a
supported backend, and have tests and docs written. As you noted, this
isn't a particularly difficult task - it just needs someone to do the
work. I promise that if the patch gets some love and attention, I'll
put it into trunk.

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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: [Fwd: Documentation: Google-foo lost]

[Jacob Kaplan-Moss]

On Fri, Sep 19, 2008 at 2:19 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
> The question is: is it worth continuing this web-scraping and analysis
> and potentially extending it to other reference mechanisms I am unaware
> of? I don't know whether the current redirection will eventually cause
> the web search engines to throw away the old references, but it would be
> nice to be able to move them forward if possible.

Yes, this is extremely helpful. I'd like to get some better redirects
in place ASAP, so if you can work with your script to give me a
complete list I can throw 'em up. I've done a couple of things for
anyone who can help:

* I've temporarily removed the global redirect; it's just confusing.
We'll replace it with more granular redirects a bit later.

* I've added a page to the wiki for redirects:
http://code.djangoproject.com/wiki/DocumentationRedirects

* I'll start writing some code to help with the redirects. We'll need
a bit of javascript to help with the fragment redirects since the web
server doesn't get fragments; I'll get that done.

Monday morning I'm going to replace the redirects with whatever's at
the wiki page.

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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Concrete django.template Suggestions

[Armin Ronacher]

Hi everybody,

After my quite controversal blog post about Jinja and Django I summed
up some suggestions for the Django template engine that don't require
a complete reimplementation / breaking backwards compatibility :)

First of all the thread in-safeties I discovered [and the explanation
why nobody noticed so far].  First of all the explanation, because
that's probably more interesting: Per default templates are parsed and
evaluated each request so you will never notice that.  However I've
seen enough applications by now that keep the template objects in
memory where these problems become visible.  Why would anyone want to
not parse the templates each request?  Because it's a lot faster.  How
much?  ~100 req/sec versus 60 req/sec for the file browser page on
bitbucket, and that's the overall request time including all of the
request handling, http header parsing and of course database.

Where are threading bugs?  Everywhere, where a tag render method
somehow modifies the node object.  Where does this happen?  From what
I've seen so far it's done in "block", "ifchanged", "cycle" and
"extends".  Now, of course the attribute assignments happen for a
reason: they are necessary, at least for cycle and ifchanged.  Block
and extends look like accidents, they could be solved a lot cleaner
(block would put a reference to a hypothetical SuperBlock into the
context, rather than a reference to itself) and extends doesn't have
to store the evaluated value on the node at all, a local variable is
just fine.  Ifchanged and cycle however have to somewhere store the
information, and I recommend using the context object for that.  The
context could get `get_state_var`, `set_state_var` functions that can
be used to store node related information from one render call to the
next::

def get_state_var(self, node, name, default=None):
storage = self._state_vars.get(id(node), None)
if storage is not None and name in storage:
return storage[name]
return default

def set_state_var(self, node, name, value):
self._state_vars.setdefault(id(node), {})[name] = value

The cycle node could then look like this::

class CycleNode(Node):
def __init__(self, cyclevars, variable_name=None):
self.cycle_vars = map(Variable, cyclevars)
self.variable_name = variable_name

def render(self, context):
pos = context.get_state_var(self, 'pos', 0)
value = self.cycle_iter[pos].resolve(context)
context.set_state_var(self, 'pos', (pos + 1) %
len(self.cycle_vars))
if self.variable_name:
context[self.variable_name] = value
return value

This used in all core tags makes the `Template` object thread safe,
but not the `Context` which is perfectly okay because it doesn't
happen (or should not happen) that a context object is shared between
threads.  At least I don't see a situation where this is useful.

What's harder to fix is how the i18n integration translates filter
arguments or gettext constants (those _("foo") thingies).  Currently
that happens very often at node/object creation rather than node/
object evaluation.  A good example for that problem is
FilterExpression.__init__.  The translation would have to be moved to
the resolve method in that case.  When would a language change between
template compilation and rendering?  If the language changes each
request which is a very common case on multilingual websites.

Changing the parser to a more advanced system or making the template
engine more consistent is not so important for the time being, but I
want to raise a few situations I encountered where the behaviour is
confusing:

  - cycle arguments are delimited by spaces and each item can be an
expression (however if there is a comma involved somewhere, it
seems like the tag is interpreted as comma separated list of
strings
which makes the 'cycle "foo", "bar", "baz"' yield unexpected
results.

  - On the other hand arguments for the url tag are comma delimited,
but whitespace after comma is not allowed.

  - The group-by part of the regroup tag is an expression, but
everything
else but a variable name returns unexpected results.  Furthermore
does this tag only work on dicts.  By the group-by part I'm
refering
to the expression after the "by" keyword:

  {% regroupy foo by bar as blah %}

bar is here treated as constant string, even though it's
represented
as variable in the regroup node and in the syntax.

  - Likewise ssi excepts one argument that looks like a variable, but
is
treated as constant string.

Tags to be excluded from the variable-as-string rule should be block
and load because they represent neither variables nor strings.  The
argument for block works like a label and the argument for load is a
library.

Regards,
Armin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to 

Re: [Fwd: Documentation: Google-foo lost]

[Steve Holden]

Jacob Kaplan-Moss wrote:
> On Fri, Sep 19, 2008 at 2:19 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
>   
>> The question is: is it worth continuing this web-scraping and analysis
>> and potentially extending it to other reference mechanisms I am unaware
>> of? I don't know whether the current redirection will eventually cause
>> the web search engines to throw away the old references, but it would be
>> nice to be able to move them forward if possible.
>> 
>
> Yes, this is extremely helpful. I'd like to get some better redirects
> in place ASAP, so if you can work with your script to give me a
> complete list I can throw 'em up. I've done a couple of things for
> anyone who can help:
>
> * I've temporarily removed the global redirect; it's just confusing.
> We'll replace it with more granular redirects a bit later.
>
> * I've added a page to the wiki for redirects:
> http://code.djangoproject.com/wiki/DocumentationRedirects
>
> * I'll start writing some code to help with the redirects. We'll need
> a bit of javascript to help with the fragment redirects since the web
> server doesn't get fragments; I'll get that done.
>
> Monday morning I'm going to replace the redirects with whatever's at
> the wiki page.
>   
Great. What else do I need to look for besides the section-class divs? I
can put a little more time in to this over the weekend. Documentation
needs at least as much love as code ...

regards
 Steve


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

Re: Nested Inlines in admin!!

[John]

Thanks Karen!

On Sep 19, 10:24 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 19, 2008 at 9:42 AM, John <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > I was wondering if nested inlines' will be supported in the admin in
> > any post 1.0 release. I remember seeing it mentioned in the road map
> > for the 1.0 release but I guess it was dropped due to time issues.
>
> The topic was discussed quite recently on this list:
>
> http://groups.google.com/group/django-developers/browse_thread/thread...
>
> Karen
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: incorrect field type for object_pk in contrib.comments?

[Ludvig Ericson]

On Sep 16, 2008, at 23:31, [EMAIL PROTECTED] wrote:

>
> It's intentional, usually you see an object_pk as an integer field,
> however that means it won't work with any field with a custom primary
> key, specifically those with string type pks.  And a textfield offers
> the flexibility to work with all of those.

I'm no DBA, but it doesn't take a rocket scientist to realize how  
inefficient it'll become for large datasets.

I'd say the default should be an IntegerField, just like it is for  
automatic primary keys, and then provide some mechanism for changing  
in that 0.1% corner case where the PK isn't an integer.

Ludvig Ericson

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

Re: incorrect field type for object_pk in contrib.comments?

[[EMAIL PROTECTED]]

The issue is it's a generic foreign key, so to change it at that time,
would mean the comments app would have to go through every installed
app and just look to see if any had a CharField or other non-integer
PK and then set it to be that time, since the app can't know at table
creation which models will be commentable.  I'd agree it's probably
not ideal, but I can't think of a better solution.

On Sep 19, 12:50 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
> On Sep 16, 2008, at 23:31, [EMAIL PROTECTED] wrote:
>
>
>
> > It's intentional, usually you see an object_pk as an integer field,
> > however that means it won't work with any field with a custom primary
> > key, specifically those with string type pks.  And a textfield offers
> > the flexibility to work with all of those.
>
> I'm no DBA, but it doesn't take a rocket scientist to realize how  
> inefficient it'll become for large datasets.
>
> I'd say the default should be an IntegerField, just like it is for  
> automatic primary keys, and then provide some mechanism for changing  
> in that 0.1% corner case where the PK isn't an integer.
>
> Ludvig Ericson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

m2m table names

[HenrikV]

If you imagine changing the table name of the auth.User table to
'account_user'. Should the groups relationship create a table called
'account_user_groups' or 'auth_user_groups' ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Why would render() get called multiple times?

[Karen Tracey]

On Wed, Sep 10, 2008 at 4:06 PM, Karen Tracey <[EMAIL PROTECTED]> wrote:

> We have this problem that's been seen in the wild by a couple-three people
> now:
>
> http://code.djangoproject.com/ticket/8110
>
> It apparently results from the AdminLogNode's render() function getting
> called multiple times, since the patch that protects against that by not
> modifying self.user in render fixes the issue for the last two people who
> have reported the problem.  I think that's an OK fix (render() is supposed
> to allow for being called more than once, right, since if the template tag
> is in a loop the same node will get rendered multiple times?)...but I can't
> understand why, in this case, render() is getting called more than once.
> The tag is not in any sort of a loop in admin's index.html file (and the
> reporter says that file has not been modified).  What else might cause
> render to get called multiple times for the same template node?
>
> A further bit of weirdness is that the problem is reported to only occur
> with DEBUG set to False.  If deubug is on, no problem.  If it's off,
> sporadic internal server errors on the main admin page.  I can't recreate it
> at all, regardless of debug setting or deployment method.  Any ideas?
>

Armin's notes on template thread-safety reminded me of this little problem.
If I'm reading his notes correctly, multiple threads re-using the same
parsed template object could cause this problem.  But, he also notes that by
default templates are parsed and evaluated for each request, so the app
would have to do something to cause the same parsed template to be used for
multiple requests...and from a quick look I can't see that Admin does
anything like that?

Does anyone have an opinion on whether it would be better to just put the
existing fix in as-is, or leave this open for a bit to try to understand why
it is happening?

Karen

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

Development process and 1.1 release schedule posted

[Jacob Kaplan-Moss]

Hi folks --

Following up from my RFC earlier this week, I've posted the new
release process
(http://docs.djangoproject.com/en/dev/internals/release-process/) and
1.1 schedule (http://code.djangoproject.com/wiki/Version1.1Roadmap).

I've made a couple changes from the drafts:

* I've more clearly denoted that 6 months will be the norm, and longer
schedules the exception. There seems to be a general consensus that
more frequent releases are better.

* I've updated the branch policy
(http://docs.djangoproject.com/en/dev/internals/contributing/#branch-policy)
to explain how DVCS branches will work, and to have more clear rules
for SVN branches.

* I've added an explicit feature proposal deadline (would that be a
"pony freeze", perhaps?) to the 1.1 schedule.

182 days until 1.1...

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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: RFC: django.template refactoring (#7806)

[Vinay Sajip]

On Sep 19, 4:16 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Fri, Sep 19, 2008 at 4:15 AM, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> > There are philosophical differences between Django and Jinja
> > templating about how much power there should be in the templating
> > engine. Django's philsophy is to keep the power to the minimum
> > required - "templates are not programs" - and I think we all
> > understand this, but apart from that point, can you [or one of the
> > other core devs] be more specific about what you think these different
> > goals are?
>
> http://docs.djangoproject.com/en/dev/misc/design-philosophies/#templa...
>
> In particular:
>
> """
> The goal is not to invent a programming language. The goal is to offer
> just enough programming-esque functionality, such as branching and
> looping, that is essential for making presentation-related decisions.
>
> The Django template system recognizes that templates are most often
> written by designers, not programmers, and therefore should not assume
> Python knowledge.
> """
>

Jacob,

Thanks for replying - I did say "apart from the templates-are-not-
programs point", which you've emphasised here. And I was asking about
*differences* between Jinja and Django, because that was what
Malcolm's post was about. From the information that you linked to, on
a point-by-point reading and comparing with Jinja, it seems that Jinja
was avowedly inspired by Django templates and, in large measure,
follows the same philosophy. So I don't think Armin's comparison was
such an apples-and-oranges one. The one big difference is in Jinja
allowing more complex expressions, including function calls, in
templates. If this expressive power was toned down, there would appear
to be little difference other than implementation details. (I won't go
through the points blow-by-blow, unless anyone expresses an interest.)

On the question of expressive power, is "elif" explicitly left out
because it's considered an advanced concept for designers to
understand - more complex than "if" and "else"? Or can it be added
without breaking the design principles behind Django templates? And is
it really strongly felt that whereas "{% ifequal a b %}" is OK for
designers to understand, "{% if a = b %}" is considered too advanced?

>From Armin's recent post

http://groups.google.com/group/django-developers/browse_thread/thread/ba0644b835e3ec40

it would appear that Django templates are not safe if shared across
multiple threads, so they have to be loaded anew for each request.
This is the default, but it extracts a moderately large performance
penalty. But caching Template objects to improve performance would be
a no-no, so wouldn't it be worth at least mentioning it somewhere in
the docs?

Also, from Karen Tracey's recent post

http://groups.google.com/group/django-developers/browse_thread/thread/f7d638d1f79ec43c

it appears there may be scenarios where even with default settings,
there might be situations where render() code gets called on the same
node by different threads.

Regards,

Vinay Sajip

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

Re: Proposal: installmedia command - A story for distributing media with apps

[Brian Beck]

I noticed that elwaywitvac just posted this management command here:
http://www.djangosnippets.org/snippets/1066/

I also have an implementation that I'll post when I get home.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Postgresql transaction aborts, despite being in autocommit mode

[Richard Davies]

Hi all,

I believe that I have found a bug in Django 1.0 for both Postgresql
backends, but would very much appreciate your thoughts in case I am
misunderstanding something... The test case seems clear enough that
this must have been noticed before, and there is an existing open
ticket and patch for a related problem.

I have a simple model:


class Test(models.Model):
  data1 = models.IntegerField(unique=True)
  data2 = models.IntegerField()


and a view using it:


def render(request):
  a = Test()
  a.data1 = 1
  a.data2 = 10
  a.save()

  b = Test()
  b.data1 = 1
  b.data2 = 20
  try:
b.save()
  except IntegrityError:
# Expected since data1 not unique
pass

  c = Test()
  c.data1 = 2
  c.data2 = 30
  c.save()

  return HttpResponse('Test')


All of this code is run without transaction middleware, which I
believe means that every database operation should auto-commit
individually, regardless of whether the database supports
transactions.


Correct behavior is for the view to return 'Test' and leave objects
'a' and 'c' in the database. I observe this on both MySQL with MyISAM
tables and MySQL with InnoDB tables (which supports transactions).

With Postgresql*, an internal error is raised by the line 'c.save()',
with the text 'current transaction is aborted, commands ignored until
end of transaction block'. Only object 'a' is left in the database.


I can work around the Postgresql behaviour by adding an explicit
savepoint and rollback around 'b.save()', but surely this should not
be necessary? I am operating in autocommit mode, so there should be no
transaction present. Equally, MySQL InnoDB does not require these.


I believe this boils down to the same issue as ticket [3460] - both
the psycopg1 and psycopg2 backends are using the wrong isolation
level, as a result of which the Django SQL is wrapped by psycopg
inside an implicit transaction. I have tried using the [3460] patch,
which gives me the Postgresql behaviour that I expected.


Your thoughts very much appreciated - assuming I understand the
meaning of "autocommit" this seems quite a fundamental problem.

Best regards,

Richard.


* My test is with Postgresql 8.1.4 and Psycopg2 2.0.7. However, if my
diagnosis is correct, then this will hold for all versions and also
for the Psycopg1 backend.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Postgresql transaction aborts, despite being in autocommit mode

[Jacob Kaplan-Moss]

Hi Richard --

What you've described is documented behavior for PostgreSQL (try
googling for "commands ignored until end of transaction block") --
Postgres does not alow *any* commands in a transaction after a
database error; you have to commit or rollback first.

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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Postgresql transaction aborts, despite being in autocommit mode

[Collin Grady]

This is related to http://code.djangoproject.com/ticket/3460

-- 
Collin Grady

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

Re: Proposal: installmedia command - A story for distributing media with apps

[Brian Beck]

On Sep 19, 4:26 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> I also have an implementation that I'll post when I get home.

I just posted my collectmedia (I liked the name Rajeev used) command
here: http://www.djangosnippets.org/snippets/1068/

It's a long snippet because it includes an interactive mode and sets
permissions (see below).  For testing, I recommend running with -i and
-n (interactive mode and dry run mode, respectively).  I've tested it,
but you should probably back up your media first.

Features:

If multiple apps provide a media file of the same name, use the file
provided by the app listed first in INSTALLED_APPS - this mimics the
template loader behavior.  In interactive mode (-i), you may specify
which app to select from for each such file.  With this command, best
practice would be to put media files at app/media/appname/... - just
like templates.

It attempts to be "smart" about permissions by using MEDIA_ROOT's
permissions and ownership on all the files it creates.  So, if
MEDIA_ROOT is owned by apache/www-data for instance, the media files
should, too.

You may provide a directory other than MEDIA_ROOT to copy to.  You may
also use symbolic links instead of copying, but this doesn't work on
Windows, so copying is the default behavior.  See the code for the
other options...

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

Re: Why would render() get called multiple times?

[Malcolm Tredinnick]

On Fri, 2008-09-19 at 15:33 -0400, Karen Tracey wrote:
[...]
> 
> Does anyone have an opinion on whether it would be better to just put
> the existing fix in as-is, or leave this open for a bit to try to
> understand why it is happening?

I personally would want to understand what's really going on before
committing anything.

Malcolm

> 


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

Re: Concrete django.template Suggestions

[Malcolm Tredinnick]

On Fri, 2008-09-19 at 09:08 -0700, Armin Ronacher wrote:
[...]
> Where are threading bugs?

We're all going to find this easier if the right words are used.
Template class instances are mutable objects that hold their current
state. This is a design choice, not a bug. When something is done
intentionally and works as intended, that's a design choice, not a bug.
The distinction is important, as it leads to discussions being made as
to the differences in opinions about the decision, not an all-or-nothing
bug fix. It's for the same reason we don't refer to dictionaries, lists,
sets and other mutable Python objects as having thread bugs.

>   Everywhere, where a tag render method
> somehow modifies the node object.  Where does this happen?  From what
> I've seen so far it's done in "block", "ifchanged", "cycle" and
> "extends".  Now, of course the attribute assignments happen for a
> reason: they are necessary, at least for cycle and ifchanged.  Block
> and extends look like accidents, they could be solved a lot cleaner
> (block would put a reference to a hypothetical SuperBlock into the
> context, rather than a reference to itself) and extends doesn't have
> to store the evaluated value on the node at all, a local variable is
> just fine. 

That would change the rendering behaviour, however. Whether they were
accidents originally or not isn't really a concern right this moment.
Backwards compatibility is. The approach is certainly worth considering
(we have to do something like this for reset-ability of cycling, for
example), but the backwards-incompatible effects needs to be itemised
and addressed as well.

[...]
> This used in all core tags makes the `Template` object thread safe,
> but not the `Context` which is perfectly okay because it doesn't
> happen (or should not happen) that a context object is shared between
> threads.  At least I don't see a situation where this is useful.

All that leaves is the thousands of third-party tags. Again, trying to
reach for some guarantee that instances can be shared between threads
has quite an extensive set of secondary effects. It might be preferable
to say that our current situation of being a mutable object holding
state is not that bad, rather than causing massive disruptions to the
userbase, since the current code still meets the "fast enough" criteria
for a very large group of uses.

> What's harder to fix is how the i18n integration translates filter
> arguments or gettext constants (those _("foo") thingies).  Currently
> that happens very often at node/object creation rather than node/
> object evaluation.  A good example for that problem is
> FilterExpression.__init__.  The translation would have to be moved to
> the resolve method in that case.  When would a language change between
> template compilation and rendering?  If the language changes each
> request which is a very common case on multilingual websites.

That's actually a known. From memory, it's buried in a ticket talking
about something else, but I know it's been on my list of things to
address for a while now and pre-1.1 is probably the time frame where I'm
goign to be doing a lot of i18n work.

A quite reasonable goal is that template instances should be cacheable
right after they've been loaded (we already know that rendering changes
state, but right after loading they're always in the same state). That
means being pickle-able and, later, unpickle-able in a different view
with, as you note, a different active locale.

There are actually a whole swathe of problems with the various i18n
template tags that need to be cleaned up. They're in line behind sorting
some of the thing like making Variable() consistent and stuff like that
so that we can reuse the common support stuff. That will come out of
merging the work Johannes Dollinger is proposing with the existing code.
So there's an ordering of fixes going on there, but it's certainly on my
personal radar.
> 
> Changing the parser to a more advanced system or making the template
> engine more consistent is not so important for the time being, but I
> want to raise a few situations I encountered where the behaviour is
> confusing:
> 
>   - cycle arguments are delimited by spaces and each item can be an
> expression (however if there is a comma involved somewhere, it
> seems like the tag is interpreted as comma separated list of
> strings
> which makes the 'cycle "foo", "bar", "baz"' yield unexpected
> results.
> 
>   - On the other hand arguments for the url tag are comma delimited,
> but whitespace after comma is not allowed.
> 
>   - The group-by part of the regroup tag is an expression, but
> everything
> else but a variable name returns unexpected results.  Furthermore
> does this tag only work on dicts.  By the group-by part I'm
> refering
> to the expression after the "by" keyword:
> 
>   {% regroupy foo by bar as blah %}
> 
> bar is here treated as constant string, even though it's
> represented
> a

Re: Why would render() get called multiple times?

[Manuel Saelices]

On 20 sep, 03:32, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-09-19 at 15:33 -0400, Karen Tracey wrote:
>
> [...]
>
>
>
> > Does anyone have an opinion on whether it would be better to just put
> > the existing fix in as-is, or leave this open for a bit to try to
> > understand why it is happening?
>
> I personally would want to understand what's really going on before
> committing anything.

The reason is that first time self.user is loaded with an user object
and second time is loaded a integer.

Offtopic: Two weeks ago, I tried to optimize template system by
caching compiled templates loaded by Django "loader". The results was
wonderful but in admin site was no working. I had no time to fix
problem but now I've seen #8110 patch and was perfect fix for my
issue. Now I've created a ticket for that optimization hack:

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

Regards,
Manuel Saelices

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

Re: m2m table names

[Russell Keith-Magee]

On Sat, Sep 20, 2008 at 2:47 AM, HenrikV <[EMAIL PROTECTED]> wrote:
>
> If you imagine changing the table name of the auth.User table to
> 'account_user'. Should the groups relationship create a table called
> 'account_user_groups' or 'auth_user_groups' ?

I'm unclear if this is a user 'how to' question, or a badly phrased
suggestion for an improvement to Django.

If it's a user question, it should be asked on django-users.
django-developers is for discussing the development of django itself.
That said - unless overridden with the db_table setting or the use of
a through model, the m2m table name will be "model.db_table +
field_name" - in your case, that means account_user_groups.

If this is a suggestion for an improvement to Django, can you clarify
what exactly you are proposing? The current m2m table naming scheme
has been in place since the very beginning, and with the exception of
a few customizations, it hasn't changed in all that time. Why do you
think it is necessary to change the naming scheme?

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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Postgresql transaction aborts, despite being in autocommit mode

[Richard Davies]

Hi Jacob,

I agree that this is documented behavior for PostgreSQL
_transactions_.

The reason that I think it's a bug is that I shouldn't be in a
transaction at all - as I understand 
http://docs.djangoproject.com/en/dev/topics/db/transactions/
, the default behaviour should be auto-commit in which each individual
change is committed independently and individually, and there is no
transaction taking place. This is what I see from MySQL InnoDB.

My problem is that I can't get this auto-commit behavior from
PostgreSQL with Django - either in the default mode or even when I
explicitly use TransactionMiddleware with the @transaction.autocommit
decorator or set DISABLE_TRANSACTION_MANAGEMENT to True.


My suggestion is that changing the psycopg isolation level to zero (as
per ticket 3460) will give true auto-commit behaviour for PostgreSQL,
since otherwise psycopg wraps the Django SQL in a transaction block.
Note both psycopg1 and psycopg2 both provide an explicit function to
switch them into autocommit mode by setting the isolation level to
zero (search for 'autocommit' in 
http://www.initd.org/svn/psycopg/psycopg2/trunk/lib/psycopg1.py
and http://www.initd.org/svn/psycopg/psycopg1/trunk/connection.c
respectively).

Cheers,

Richard.


On Sep 20, 12:12 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Hi Richard --
>
> What you've described is documented behavior for PostgreSQL (try
> googling for "commands ignored until end of transaction block") --
> Postgres does not allow *any* commands in a transaction after a
> database error; you have to commit or rollback first.
>
> 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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---