gt; I have a query concerning the lack of a ON DELETE CASCADE clause to the
> foreign key constraints generated for PostgreSQL (using Django 1.8.11) on
> the default through tables generated for ManyToManyField.
>
>
> I was unable to find any related issues (”ManyToMany cascade”
On Wednesday 23 March 2016 11:50:59 Hugo Chargois wrote:
>
> ... MySQL's REPEATABLE READ may have
> it flaws, it may cause repeating bugs because that level is a bit awry,
> with its reads and writes that don't work the same, but all in all, it IS a
> higher isolation level than READ COMMITTED. It
While there are some different opinions expressed here (mine included), the
rough consensus seems to be to apply the for_update() patch to 1.8.x (it is
neither needed nor applicable to 1.9.x) and change the transaction isolation
level for 1.10 and going forward.
To the best of my knowledge, nob
What's the current status on this? Is the .for_update() change mentioned
in the bug report the best way to go? Is anyone working on a PR?
On 03/18/2016 05:15 PM, Karen Tracey wrote:
This is the 2nd major issue I can recall caused by MySQL default of
REPEATABLE READ transaction isolation level.
Le mardi 22 mars 2016 23:33:10 UTC+1, Shai Berger a écrit :
> It is Django's job to try, as best as it can, to fulfill these
expectations.
How could I disagree? Of course, if there is one single sensible, obvious
default, that would help 99.9 % of users, like your webserver analogy, it
should
On Tuesday 22 March 2016 11:57:03 Hugo Chargois wrote:
>
> I'm unsure that your relentless rant against MySQL is useful in this topic.
I'm sorry if anyone sees it as a rant. It is intended as a technical argument
that MySql's REPEATABLE READ is unsuitable for use as a default by Django.
>
> Yo
Le mardi 22 mars 2016 00:11:31 UTC+1, Shai Berger a écrit :
> I disagree. The ORM cannot keep you safe against MySql's REPEATABLE READ.
>> Incidentally, to prove my point,
>> this has been changed in Django 1.9 and data-loss doesn't happen
anymore,
>> in that same default isolation level.
>>
Hi,
On Monday 21 March 2016 13:01:27 hcharg...@medici.tv wrote:
>
> I agree with Karen that documenting that some functions don't work is not
> helping. Especially since this is Django's fault, not MySQL's. I mean,
> sure, MySQL has some very weird isolation modes, I definitely agree with
> Shai
On 21 Mar 2016, at 15:02, Hugo Chargois wrote:
>
> But here, we have "two non-conflicting updates (no-ops, even) causes data to
> be lost". I bet no one would call this safe.
Yes, this one was clearly a bug (and, if I understand correctly, it was
resolved by a not-directly-related change, orig
Le lundi 21 mars 2016 13:35:19 UTC+1, Aymeric Augustin a écrit :
>
>
> The problem is to determine what “safe” means here :-) I’m afraid this
> won’t be possible in general (at least not in a remotely efficient fashion)
> because Django inevitably depends on the guarantees of the underlying
> da
Hello,
> On 21 Mar 2016, at 12:01, hcharg...@medici.tv wrote:
>
> In my opinion, the fix should not be to set a different default isolation
> level, as that could trigger other problems that may be very hard to find. I
> was lucky to find this one. I think that Django should find sequences of
Shai Berger, this explanation is pure gold! Definetely better than MySQL's
one.
Now I may agree on that changing the isolation level should be probably
left to a major release, or either have a huge warning on the patch notes.
I personally can't think of any project I have done that this would
Hi,
I'm the ticket OP.
As a user, I definitely expect that my ORM won't eat my records when I save
something, even with concurrency. Furthermore, I expect it to work with the
default configuration of the backend, or if I have to change it, the ORM
should refuse to work until the configuration
We’ve had, and known about, such problems for so long that I’m also
inclined not to make that change in already released versions.
--
Aymeric.
> On 21 Mar 2016, at 12:33, Anssi Kääriäinen wrote:
>
> This being MySQL I wouldn't be surprised if changing the isolation
> level would introduce new
This being MySQL I wouldn't be surprised if changing the isolation
level would introduce new problems. Also, user code might rely on
Django using repeatable read. If we introduce the change in to stable
releases, we risk breaking sites that work perfectly well currently.
To me this is against our b
My recommendation to backport is based on the observation that the peculiar
REPEATABLE READ behavior is highly conductive to data loss in the presence of
concurrency, combined with a sense that it is not very well known; I find it
much more likely that the change will fix broken code than break
I'm strongly -1 on changing the default isolation level in a minor
release. We can recommend users switch the level and complain loudly
if they don't. But just changing the isolation level has potential for
breaking working code.
- Anssi
On Mon, Mar 21, 2016 at 9:27 AM, Shai Berger wrote:
> Fir
On 21 Mar 2016, at 01:25, Cristiano Coelho wrote:
>
> What performance changes can you expect doing this change? It is probably
> that default on MySQL for a good reason.
Barring implementation weirdness, reducing the isolation level is supposed to
improve performance (if it makes a difference
First of all, I would like to say that I strongly support the move to READ
COMITTED, including backporting it to 1.8.x.
But we also need to explain: REPEATABLE READ is a higher transaction isolation
level than READ COMMITTED. If you have problematic code, it should lead to
more deadlocks and/or
What performance changes can you expect doing this change? It is probably
that default on MySQL for a good reason.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop re
+1 for me, too... this aligns with "safe/secure by default".
--
C
On 21/03/16 09:13, Aymeric Augustin wrote:
I agree with Karen.
--
Aymeric.
On 18 Mar 2016, at 22:15, Karen Tracey mailto:kmtra...@gmail.com>> wrote:
This is the 2nd major issue I can recall caused by MySQL default of
REPEATA
I agree with Karen.
--
Aymeric.
> On 18 Mar 2016, at 22:15, Karen Tracey wrote:
>
> This is the 2nd major issue I can recall caused by MySQL default of
> REPEATABLE READ transaction isolation level. I think Django should simply
> switch itself to a default of using READ COMMITTED, consistent
This is the 2nd major issue I can recall caused by MySQL default of
REPEATABLE READ transaction isolation level. I think Django should simply
switch itself to a default of using READ COMMITTED, consistent with (all?)
other supported database backends, and document how, if a user really
really wants
I have a query concerning the lack of a ON DELETE CASCADE clause to the
foreign key constraints generated for PostgreSQL (using Django 1.8.11) on
the default through tables generated for ManyToManyField.
I was unable to find any related issues (”ManyToMany cascade” Search
Results – Django
I can't tell if it is a bug on MySQL or not, but I did understand the same
as you (the first example with Session A and Session B makes it more clear)
so I can't quite understand how did the poster get that issue. I would like
a similar example as the one in the docs, but with a delete in the mi
Hi,
I just commented on the ticket, but wanted to clarify a few things here:
On Tuesday 15 March 2016 00:48:02 Cristiano Coelho wrote:
> The django-admin interface is quite bad at handling concurrent
> modifications, this is one problem that might not happen on other backends
> and is quite criti
The django-admin interface is quite bad at handling concurrent
modifications, this is one problem that might not happen on other backends
and is quite critical, but other issues (that ain't critical like data loss
but might cause unexpected errors) like two people viewing a model with
some inli
Could some MySQL users take a look at ticket #26347 [0] and recommend how
to proceed? I think it's probably not a new issue but I'm a bit surprised
it hasn't come up before if so.
[0] https://code.djangoproject.com/ticket/26347
--
You received this message because you are subscribed to the Goo
Many thanks for the answer! Very Now I made a big step forwards:
class CustomInterestsInline(admin.TabularInline):
model = models.CustomInterests
extra = 9
class CustomSportsInlilne(admin.TabularInline):
model = models.CustomSports
extra = 9
class CustomMusicInline(admin.Tabul
Many thanks for the answer! Very Now I made a big step forwards:
class CustomInterestsInline(admin.TabularInline):
model = models.CustomInterests
extra = 9
class CustomSportsInlilne(admin.TabularInline):
model = models.CustomSports
extra = 9
class CustomMusicInline(admin.Tabul
>>
>>
>> class CustomInterests(models.Model):
>>
>> WEIGHT = [(y, y) for y in range(1, 7)]
>>
>> interest = models.ForeignKey(Interests)
>> custominterest = models.ForeignKey(CustomUserprofileInterests)
>> rating = models.SmallIntegerField(
rests)
> rating = models.SmallIntegerField(choices=WEIGHT)
>
> I want to accomplish a rating on each relation in the 'interests =
> ManyToManyField' in my CustomUserprofile. The Interests-Model HAS to have
> an OWN, self relating rating in each 'interest' entry, NOT re
Hi,
> Startet lot of investigation and the 'through' option seems to be the
> solution? Don't got it really because in my Admin there is NO field to
> choose some 'interests' and an option to rate it.
Did you try using InlineModelAdmin
(https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#wor
eld(choices=WEIGHT)
I want to accomplish a rating on each relation in the 'interests =
ManyToManyField' in my CustomUserprofile. The Interests-Model HAS to have
an OWN, self relating rating in each 'interest' entry, NOT related to the
CustomUserprofile.
Startet lot of inve
On Fri, Mar 28, 2014 at 2:29 PM, anubhav joshi wrote:
>
> values() and values_list() are both intended as optimisations for a
>> specific use case - retrieval of subsets of data without the overhead of
>> creating a model instance. This metaphor completely falls apart when
>> dealing with m2m rela
> values() and values_list() are both intended as optimisations for a
> specific use case - retrieval of subsets of data without the overhead of
> creating a model instance. This metaphor completely falls apart when
> dealing with m2m relations, because the the "one row, one object" metaphor
You're missing an important third option here: do nothing, and document the
fact that "values" over an m2m is an inherently nonsense operation in an
ORM context.
values() and values_list() are both intended as optimisations for a
specific use case - retrieval of subsets of data without the overhea
There has been quite a discussion on the ticket regarding this
Refs. : https://code.djangoproject.com/ticket/22268
I think we must discuss and decide what should be the solution we should be
working towards.
Until now there have been two strategies:
1.) The query generated is correct therefore,
W
Ok
Thaks for you reply.
On Tue, Aug 21, 2012 at 3:37 AM, Karen Tracey wrote:
> Please ask questions about using Django on django-users. The topic of this
> list is the development of Django itself.
>
> Thanks,
> Karen
>
> --
> You received this message because you are subscribed to the Google G
Please ask questions about using Django on django-users. The topic of this
list is the development of Django itself.
Thanks,
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@googl
Hello
I'm new in Django using 1.4version.
So got some error.
'myapp.models.AdversiteImages'> has no ForeignKey to
*
MODEL*
class AdversiteImages(models.Model):
image = models.FileField(u'Photo' , upload_to='adversiteimage/%Y/%
m/%d', null=True, blank=True)
class Adversite(models.Model):
So the only option I have for now is to iterate through each object and
call create right ?
list_companies = [Company(url='...'), Company(url='...')]
for c in list_companies:
w.companies.create(c)
Best,
Michael
Le lundi 7 mai 2012 22:46:10 UTC+2, Michael a écrit :
>
> ok, I created it: htt
ok, I created it: https://code.djangoproject.com/ticket/18285
Le lundi 7 mai 2012 22:04:31 UTC+2, Anssi Kääriäinen a écrit :
>
> On May 7, 10:53 pm, Michael wrote:
> > Hi,
> >
> > I am using bulk_create on a ManyToMany relationship and I think there is
> a
> > bug.
> > Here is the code:
On May 7, 10:53 pm, Michael wrote:
> Hi,
>
> I am using bulk_create on a ManyToMany relationship and I think there is a
> bug.
> Here is the code:
> class Company(models.Model):
> url = models.URLField(unique=True)
>
> class Website(models.Model):
> url = models.URLField(unique=True)
>
Hi,
I am using bulk_create on a ManyToMany relationship and I think there is a
bug.
Here is the code:
class Company(models.Model):
url = models.URLField(unique=True)
class Website(models.Model):
url = models.URLField(unique=True)
companies = models.ManyToManyField(Company, null=True
On Feb 6, 8:45 pm, Simon Meers wrote:
> 2011/2/5 Carl Meyer
> > 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 table
2011/2/5 Carl Meyer
>
> 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
>
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
e able to come up with is what you're gonna get.
Sorry.
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
reaso
ostgroups')
Then Host.host_groups would be a RelatedManager that will give you all
instances of HostGroup that are mapped to that Host. Letting you do
something like this:
my_host = Host.objects.all()[0]
my_groups = host.host_groups.all()
Notice that the 'related_name' parameter of a Many
_groups = host.host_groups.all()
Notice that the 'related_name' parameter of a ManyToManyField is the
name of the attribute placed on the other model for the reverse
reference.
--
Michael
On Fri, 2011-02-04 at 13:36 -0800, Mike Lindsey wrote:
> Maybe it's a too large of a lu
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?
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='%
Can you give an example of the model(s) you're talking about?
-- Gert
Mobile: +32 498725202
Twitter: @gvangool
Web: http://gert.selentic.net
On Thu, Feb 3, 2011 at 22:36, Mike Lindsey wrote:
> I'm doing something with bidirectional ManyToManyFields, in a project
> I'm working on, that is resu
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 advice on how to fix my problem,
without losing the easy A
On Jun 11, 1:11 pm, Russell Keith-Magee
wrote:
> On Fri, Jun 11, 2010 at 6:47 PM, George Sakkis
> wrote:
> > Maybe I'm missing something but I don't see why the lack of of
> > remove() and add() for ManyToManyFields with 'through' model is
> > necessary.
>
> > For remove, the docs say "The remo
On Fri, Jun 11, 2010 at 6:47 PM, George Sakkis wrote:
> Maybe I'm missing something but I don't see why the lack of of
> remove() and add() for ManyToManyFields with 'through' model is
> necessary.
>
> For remove, the docs say "The remove method is disabled for similar
> reasons (to add)" but it's
Maybe I'm missing something but I don't see why the lack of of
remove() and add() for ManyToManyFields with 'through' model is
necessary.
For remove, the docs say "The remove method is disabled for similar
reasons (to add)" but it's not clear why. All it is required for
"beatles.members.remove(joh
On Sep 25, 11:23 am, Ramiro Morales wrote:
>
> I suspect there is a clash between the names of your m2M and FK fields
> (category, category_id), try changing one of them so there isn't one
> relationship field with a name equal to the name of the other plus
> '_id'.
>
> Note that I'm not saying t
attempt
> to view it in the admin interface, it generates incorrect SQL for the
> ManyToManyField:
> category_id = models.ForeignKey('ontology.Category',
> db_column='category_id',
> verbose_name='Ontology Category')
>
> The in
rts_to_category',
verbose_name='Associated categories',
help_text='Select all categories related to this report')
right_column = models.TextField(blank=True)
Note that the generated SQL query for the ManyToManyField is correct,
in particular, it respec
On Tuesday 30 June 2009 09:34:19 Alex Rades wrote:
> Hi,
> I've also asked on the users ml but got no anwser. Maybe you can
> undestand the question better?
Please don't do that - the developers' list and the users' list have
distinct purposes, and the fact that you didn't get an answer on the
Hi,
I've also asked on the users ml but got no anwser. Maybe you can
undestand the question better?
Hi,
I have a couple of models like:
class Album(models.Model):
title = models.CharField(max_length=255)
class Image(models.Model):
image = models.ImageField(upload_to='images/')
albums =
Oops, sorry. I meant form's meta.
Something like this:
class GroupForm(ModelForm):
class Meta:
model = Group
m2m_model = User
Looks like more logical thing, than I suggested at the beginning.
On Jan 24, 6:53 am, Malcolm Tredinnick
wrote:
> On Fri, 2009-01-23 at 00:12 -0800,
On Fri, 2009-01-23 at 00:12 -0800, Evgeniy Ivanov wrote:
> On Jan 23, 3:17 am, Malcolm Tredinnick
> wrote:
> > Addressing this only in the admin would be short-sighted, however. A for
> > field that new how to handle reverse relations would be the first step
> > and then allowing the admin to use
On Jan 23, 3:17 am, Malcolm Tredinnick
wrote:
> Addressing this only in the admin would be short-sighted, however. A for
> field that new how to handle reverse relations would be the first step
> and then allowing the admin to use that is the second one.
>
Maybe better approuch is in model's met
Hi Malcolm,
> I look forward to reading your patch. :-)
OK.
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django develop
On Thu, 2009-01-22 at 21:51 +0600, Yuri Baburov wrote:
> Hi, and what's wrong with writing a fix for admin to make "inverted"
> m2m relation to show m2m if specified in list_display list? I know
> it's not easy to do for one who is not django creator, but since it's
> open source... ;)
>
> Core d
On Fri, Jan 23, 2009 at 3:58 AM, Evgeniy Ivanov wrote:
>
> On Jan 22, 6:51 pm, Yuri Baburov wrote:
>> Hi, and what's wrong with writing a fix for admin to make "inverted"
>> m2m relation to show m2m if specified in list_display list? I know
>> it's not easy to do for one who is not django creato
On Jan 22, 6:51 pm, Yuri Baburov wrote:
> Hi, and what's wrong with writing a fix for admin to make "inverted"
> m2m relation to show m2m if specified in list_display list? I know
> it's not easy to do for one who is not django creator, but since it's
> open source... ;)
Oh, it could be interest
e to
>> find any fine solution, but specifying M2M in both models and creating
>> tables manually (since syncdb tries to create two tables).
>> I herd in the IRC, that such thing (editing in both forms) is
>> abnormal, but I disagree.
>> So I tried to use intermidiary mo
d to use intermidiary model like described in the docs, but
> it is really another thing (not "pure" m2m). Another solution is
> hardcording the form, but it will require extra save code, I don't
> like it too.
>
> I think that if you add special arg (create_table) to Many
I think that if you add special arg (create_table) to ManyToManyField
it can be easily implemented using models/fields/related.py:751.
If you think it can go, I will create a ticket.
Also there is (a kind of offtop) a very cute thing:
http://www.djangosnippets.org/snippets/962/
Why is
It seems I was unbelievably blind and not seeing the spyglass icon on
M2M fields. Please ignore me :)
On Sep 29, 5:48 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> After miserably failing at making it possible to use a field
> with 10k choices, I've decided to take a new approach in the admin.
>
After miserably failing at making it possible to use a field
with 10k choices, I've decided to take a new approach in the admin.
Right now I'm writing up a widget which would take the m2m field (for
raw_admin_fields) and output it just as it would a foreign key, except
one input per line. This
Please send usage questions to django-users - this list is for the
development of django itself.
--
Collin Grady
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
pany = models.ForeignKey(Company)
loc = models.ManyToManyField(Area)
...
And I wanna display field "loc" in Admin's list_display, but that's
impossible because it's ManyToManyField and only way to do that is to write
down proper me
On Thu, 2007-03-29 at 11:17 +0800, TerryH wrote:
> Dear list,
>
> I try to follow the doc on
> http://www.djangoproject.com/documentation/models/many_to_many/
> seems we could not compose the filter with Q (from django.db.models import Q)
It's a known bug. Using the same field in the Q object ge
Dear list,
I try to follow the doc on
http://www.djangoproject.com/documentation/models/many_to_many/
seems we could not compose the filter with Q (from django.db.models import Q)
example on the doc:
>>> Article.objects.filter(publications=p1)
[, ]
>>> Article.objects.filter(publications=p2)
[]
On 12/8/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 12/8/06, Deryck Hodge <[EMAIL PROTECTED]> wrote:
> >
> > Hi, all.
> >
> > Regarding the join table that is created on ManyToMany relationships,
> > there doesn't seem to be a way to override the name given to the
> > table. Am I ov
On 12/8/06, Deryck Hodge <[EMAIL PROTECTED]> wrote:
>
> Hi, all.
>
> Regarding the join table that is created on ManyToMany relationships,
> there doesn't seem to be a way to override the name given to the
> table. Am I overlooking this somehow? If not, does anyone else think
> a join_table opti
Hi, all.
Regarding the join table that is created on ManyToMany relationships,
there doesn't seem to be a way to override the name given to the
table. Am I overlooking this somehow? If not, does anyone else think
a join_table option would be as useful as the db_table one?
Cheers,
deryck
--
D
On 9/30/06, mdornseif <[EMAIL PROTECTED]> wrote:
>
> I now spent to long debugging my model - I had missed the
> ManyToManyField documentation regarding the symmetrical parameter and
> relying on the related_name parameter.
>
> To me it seems that when symmetrical=True,
I now spent to long debugging my model - I had missed the
ManyToManyField documentation regarding the symmetrical parameter and
relying on the related_name parameter.
To me it seems that when symmetrical=True, related_name is ignored.
Shouldn't we therefore add something like
.com/ticket/2232 (mainly russelm's attention as
>> > it appeared after his checkin 3195).
>>
>> Paying attention now :-)
>>
>> > Basically ManyToMany relations don't work when you try to get related
>> > queryset from a model where ManyToMan
On 6/25/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Russ: can you see if I've overlooked any problem there, please. It took
> a little while to track everything down and my brain may have gotten
> twisted in the process.
The anti-model-duplication logic makes sense to me from what I
und
On Sun, 2006-06-25 at 18:36 +0200, gabor wrote:
> Malcolm Tredinnick wrote:
> >
> > I can no longer cause #1796 or anything like it to fail -- and I had a
> > couple of failing examples there. I believe relative imports
> > (appname.models, etc) might now work reliably too (experiments suggest
>
On Mon, 2006-06-26 at 00:58 +1000, Malcolm Tredinnick wrote:
> I've just checked in r3202 which I believe fixes the root cause of #1796
> in a reasonably correct way. I think it also fixes #2232 for the same
> reason. It all seems to come down to the import paths being used as
> dictionary keys a
Malcolm Tredinnick wrote:
>
> I can no longer cause #1796 or anything like it to fail -- and I had a
> couple of failing examples there. I believe relative imports
> (appname.models, etc) might now work reliably too (experiments suggest
> they do), which means you no longer are reliant on your pr
Hi Russel,
> 2) I have seen the behaviour from r1796 before - for me, the problem
> ultimately turned out to be caused by a PYTHONPATH that included the
> application directory (so "from myapp.models import Foo" and "from
> myproject.myapp.models import Foo" were both legal). At the time, I
> cha
Malcolm Tredinnick wrote:
> I've just checked in r3202 which I believe fixes the root cause of #1796
> in a reasonably correct way. I think it also fixes #2232 for the same
> reason.
It does (just checked). Marking ticket fixed...
Thank you very much, Malcolm and Russel and everyone else!
--~--
; > it appeared after his checkin 3195).
>
> Paying attention now :-)
>
> > Basically ManyToMany relations don't work when you try to get related
> > queryset from a model where ManyToManyField is defined. Or is it just me?
>
> For me, all the regression tests passed
y relations don't work when you try to get related
> queryset from a model where ManyToManyField is defined. Or is it just me?
For me, all the regression tests passed at time of checkin. Following
the rest of the messages on this thread, it looks like the problems is
with model importing. 2 q
Malcolm Tredinnick wrote:
> Pretty much "just you", but it's obviously a little trickier than that.
> This is basically ticket #1796 occurring again.
I've dug a bit further and have found out that mentioned changeset
(3195) has broken only certain relations (for cross-app models and
another cas
appeared after his checkin 3195).
> >
> > Basically ManyToMany relations don't work when you try to get related
> > queryset from a model where ManyToManyField is defined. Or is it just me?
>
> Pretty much "just you", but it's obviously a little trickier than that.
rk when you try to get related
> queryset from a model where ManyToManyField is defined. Or is it just me?
Pretty much "just you", but it's obviously a little trickier than that.
This is basically ticket #1796 occurring again. You'll find it will only
fail in some very specifi
I'd like to draw some attention to ticket
http://code.djangoproject.com/ticket/2232 (mainly russelm's attention as
it appeared after his checkin 3195).
Basically ManyToMany relations don't work when you try to get related
queryset from a model where ManyToManyField is defined
Nebojša Đorđević wrote:
> When I have models like this:
>
Well, from [2457] in m-r branch django has a transaction support so I suppose
that this question is now irrelevant.
--
Nebojša Đorđević - nesh
Studio Quattro - Niš - SCG
http://studioquattro.biz/
http://djnesh.blogspot.com/ | http://
When I have models like this:
class Foo(meta.Model)
...
class Bar(meta.Model):
foos = meta.ManyToManyField(Foo)
class Baz(meta.Model)
bar = meta.ForeignKey(Bar, edit_inline=True)
object creation will go something like this:
obj = Bar(...)
obj.save() # a must, or below cod
1 - 100 of 101 matches
Mail list logo
