On 2/4/11 8:17 PM, Carl Meyer wrote:
That said, I think it's a reasonable feature request. But I don't
think defining the ManyToManyField on both models, with some kind of
"abstract" flag on one side, is the right feature request. There's no
reason it should have to be redundantly defined on both
Jython is also at release 2.5, so droppin
ig 2.5 would be harmful to that implementation.
CentOS will be the same as RHEL.
On Feb 4, 11:26 am, John Anderson wrote:
> On Feb 4, 2011, at 12:23 PM, Łukasz Rekucki wrote:
>
> > With Django 1.3 almost out, I would like to ask, what's the current
> > d
Hi Mike,
On Feb 3, 4:36 pm, Mike Lindsey wrote:
> I'm doing something with bidirectional ManyToManyFields, in a project
> I'm working on, that is resulting in duplicate attempts to create the
> intermediate tables. I'm perfectly open to suggestions of "You're
> doing it wrong" if they come with
Unfortunately you've missed the same thing that every other person who's
said the same thing has missed:
Admin forms, fieldsets, and filter_horizontal.
Django provides implicit reverse models, but they are not the same, and
do not act the same as explicit ManyToMany relationships. I'll be ver
A ManyToMany field on one model will automatically place a corresponding
field in the other model that provides the reverse lookup. For example,
if you have:
class HostGroup(models.Model):
hosts = models.ManyToManyField('Host', blank=True, null=True,
related_name='ho
Maybe it's a too large of a lunch, but I'm not sure how to answer that.
A HostGroup object has a relationship to multiple Host objects, and a
Host object has a relationship to multiple HostGroup objects. There are
also 13 or 14 more sets of paired relationships like that, spread
across six o
Does '%(class)s_hosts' represent the reverse relationship of
'%(class)s_hostgroup' like:
HostGroups <-> Hosts
Or is a tree-like structure like:
... <-> HostGroups1 <-> Hosts1 <-> HostGroups2 <-> Hosts2 <->
Where HostGroup2 has a relationship to Hosts1 and a separate
relationship to Hosts2?
Nevermind, it would seem as though transactions are only for rolling
back or preventing database changes in the case of failures, and
provide no other kind of constraints. I'm writing an article on
enforcing uniqueness constraints in Django.
On Feb 3, 1:19 am, Matteius wrote:
> Well OK so it wou
On Feb 4, 2011, at 12:23 PM, Łukasz Rekucki wrote:
> With Django 1.3 almost out, I would like to ask, what's the current
> deprecation plan of old Python versions (namely 2.4 and 2.5). The
> major argument against dropping 2.4 was RHEL support. RHEL6 seems to
> support Python 2.6 (dunno about Cen
On 2/3/11 11:22 PM, Gert Van Gool wrote:
Can you give an example of the model(s) you're talking about?
Certainly. Simplified and stripped version:
class HostGroup(models.Model):
hosts = models.ManyToManyField('Host', blank=True, null=True,
related_name='%
With Django 1.3 almost out, I would like to ask, what's the current
deprecation plan of old Python versions (namely 2.4 and 2.5). The
major argument against dropping 2.4 was RHEL support. RHEL6 seems to
support Python 2.6 (dunno about CentOS), so is that still a blocker ?
As for dropping 2.5, the
On Feb 4, 3:41 am, Rahul wrote:
> When i set this flag in DatabaseFeatures then for full test suit also
> both test cases of "contenttypes" app works fine.
>
> But i am not able to figure out why this test case was failing when we
> were not sets supports_transaction flag.
It may be worth invest
Only reason I didn't add it to the import is that it's not used in any
of the commented sample lines. But the better solution is to import it
and demonstrate using it.
Done in http://code.djangoproject.com/changeset/15415
Thanks for the suggestion.
Carl
--
You received this message because you
Hi Vivek,
On Feb 3, 1:03 am, Vivek Narayanan wrote:
> I am new to the Django community and I would like to implement a patch
> for the ticket #8809 - "Better error message when can't import url
> callback".
Welcome, and thanks for contributing!
> I was looking into the _get_callback function of
On Fri, Feb 4, 2011 at 2:45 AM, Tai Lee wrote:
> It seems to happen with very small file uploads as well. I've seen it
> reported with 30KB uploads, while at the same time 60MB uploads work. If I
> can't find a problem with the server causing disconnects, and it is actually
> on the client side
It seems to happen with very small file uploads as well. I've seen it reported
with 30KB uploads, while at the same time 60MB uploads work. If I can't find a
problem with the server causing disconnects, and it is actually on the client
side, I'll just have to continue to ignore the exception rep
Have you considered the possibility that it would be a client/browser
side error?
Both windows7 and chrome have a known open bug with large file
uploads. Many of my customers have reported this bug, all of them
using windows7 and chrome.
Has anyone seen this happening from a Mac or from Linux?
O
Thanks carl for you reply.
we were setting supports_transaction flag in settings but now i get to
know from Russ Megee's post(http://groups.google.com/group/django-
developers/browse_thread/thread/5c1c3cdfd1e4728e/) that this flag has
been moved to DatabaseFeatures.
When i set this flag in Databas
so.. at least clas_prepared works
I made some plugable application that does what I need -
https://github.com/pydevua/django-table-prefix/tree/master/table_prefix
bug general question is class_prepared signal safe and good way to do
this ?
--
You received this message because you are subscribed
19 matches
Mail list logo
