Feature request: Abstract ManyToManyField

2011-02-03 Thread Mike Lindsey
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 Admin insertion of the relationships (without
resorting to InLines, which don't seem to play nicely at all with
FieldSets).  Right now I'm getting around the problem by running
syncdb, running dbshell to drop the table it complains about, and
rerunning syncdb; repeating until syncdb finishes successfully.

What would make this exceptionally easy, is if there was the option to
set 'abstract=True' on second iteration of each of the
ManyToManyFields, telling syncdb to not attempt to create it.

Thoughts?

--
Mike Lindsey

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Feature request: Abstract ManyToManyField

2011-02-03 Thread Gert Van Gool
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 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 Admin insertion of the relationships (without
> resorting to InLines, which don't seem to play nicely at all with
> FieldSets).  Right now I'm getting around the problem by running
> syncdb, running dbshell to drop the table it complains about, and
> rerunning syncdb; repeating until syncdb finishes successfully.
>
> What would make this exceptionally easy, is if there was the option to
> set 'abstract=True' on second iteration of each of the
> ManyToManyFields, telling syncdb to not attempt to create it.
>
> Thoughts?
>
> --
> Mike Lindsey
>
> --
> 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 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Feature request: Abstract ManyToManyField

2011-02-04 Thread Mike Lindsey

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='%(class)s_hosts',
db_table='config_host_hostgroups')
class Host(models.Model):
hostgroup= models.ManyToManyField('HostGroup', blank=True, 
null=True,

related_name='%(class)s_hostgroups',
db_table='config_host_hostgroups')

I'm manipulating the data via standard admin forms, with fieldsets and 
filter_horizontal.


All the other options I've come across for this kind of data model don't 
work with fieldsets OR filter_horizontal.

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 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 Admin insertion of the relationships (without
resorting to InLines, which don't seem to play nicely at all with
FieldSets).  Right now I'm getting around the problem by running
syncdb, running dbshell to drop the table it complains about, and
rerunning syncdb; repeating until syncdb finishes successfully.

What would make this exceptionally easy, is if there was the option to
set 'abstract=True' on second iteration of each of the
ManyToManyFields, telling syncdb to not attempt to create it.

Thoughts?

--
Mike Lindsey

--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.





--
--
Mike Lindsey

--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Feature request: Abstract ManyToManyField

2011-02-04 Thread Michael
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?
-- 
Michael 

On Fri, 2011-02-04 at 10:24 -0800, Mike Lindsey wrote:
> 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='%(class)s_hosts',
>  db_table='config_host_hostgroups')
> class Host(models.Model):
>  hostgroup= models.ManyToManyField('HostGroup', blank=True, 
> null=True,
>  related_name='%(class)s_hostgroups',
>  db_table='config_host_hostgroups')
> 
> I'm manipulating the data via standard admin forms, with fieldsets and 
> filter_horizontal.
> 
> All the other options I've come across for this kind of data model don't 
> work with fieldsets OR filter_horizontal.
> > 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 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 Admin insertion of the relationships (without
> >> resorting to InLines, which don't seem to play nicely at all with
> >> FieldSets).  Right now I'm getting around the problem by running
> >> syncdb, running dbshell to drop the table it complains about, and
> >> rerunning syncdb; repeating until syncdb finishes successfully.
> >>
> >> What would make this exceptionally easy, is if there was the option to
> >> set 'abstract=True' on second iteration of each of the
> >> ManyToManyFields, telling syncdb to not attempt to create it.
> >>
> >> Thoughts?
> >>
> >> --
> >> Mike Lindsey
> >>
> >> --
> >> 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 
> >> django-developers+unsubscr...@googlegroups.com.
> >> For more options, visit this group at 
> >> http://groups.google.com/group/django-developers?hl=en.
> >>
> >>
> 
> 
> -- 
> --
> Mike Lindsey
> 

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Feature request: Abstract ManyToManyField

2011-02-04 Thread Mike Lindsey

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 or so models, in addition to a variety of single-direction 
dependencies.


Each paired relationship is represented on both models, in the Admin, 
nicely formatted and grouped via fieldsets.


On 2/4/11 12:46 PM, Michael wrote:

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?



--
Mike Lindsey

--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Feature request: Abstract ManyToManyField

2011-02-04 Thread Michael
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='host_groups',
 db_table='config_host_hostgroups')

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 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 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 or so models, in addition to a variety of single-direction dependencies.
> 
> On 2/4/11 12:46 PM, Michael wrote:
> > 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?
> 
> 

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Feature request: Abstract ManyToManyField

2011-02-04 Thread Mike Lindsey
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 very 
very happy, if I'm wrong, but so far..  To get a consistent admin view 
on both models, I apparently have to do it with explicit relationships.


On 2/4/11 4:12 PM, Michael wrote:

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='host_groups',
  db_table='config_host_hostgroups')

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 ManyToManyField is the
name of the attribute placed on the other model for the reverse
reference.




--
--
Mike Lindsey

--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Feature request: Abstract ManyToManyField

2011-02-04 Thread 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
> doing it wrong" if they come with advice on how to fix my problem,
> without losing the easy Admin insertion of the relationships (without
> resorting to InLines, which don't seem to play nicely at all with
> FieldSets).  Right now I'm getting around the problem by running
> syncdb, running dbshell to drop the table it complains about, and
> rerunning syncdb; repeating until syncdb finishes successfully.
>
> What would make this exceptionally easy, is if there was the option to
> set 'abstract=True' on second iteration of each of the
> ManyToManyFields, telling syncdb to not attempt to create it.

So what you're trying to do here is simply not supported. I'm guessing
you've already concluded as much. This means that, for now, there is
no good answer for you (that I'm aware of). Whatever hack or
workaround you are 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
reason it should have to be redundantly defined on both models.
Rather, I think it would be ideal if the admin supported including a
reverse m2m descriptor in its "fields" or "fieldsets" list, and then
could provide an m2m widget for it.

If you file a Trac issue with this feature request, I can't commit to
writing the patch to make it happen, but if you or someone else puts
together a reasonable patch for it (barring another core dev putting
forward a sensible objection to it that I'm not seeing), I'd be happy
to review and commit it (we're talking about post-1.3 at this point,
of course).

Carl

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Feature request: Abstract ManyToManyField

2011-02-04 Thread Mike Lindsey

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 models.
Rather, I think it would be ideal if the admin supported including a
reverse m2m descriptor in its "fields" or "fieldsets" list, and then
could provide an m2m widget for it.

If you file a Trac issue with this feature request, I can't commit to
writing the patch to make it happen, but if you or someone else puts
together a reasonable patch for it (barring another core dev putting
forward a sensible objection to it that I'm not seeing), I'd be happy
to review and commit it (we're talking about post-1.3 at this point,
of course).
I'm doing pretty well in the schedule for this project, so I'll see if I 
can't get a workable patch done to submit back.  If not, then I'll go 
file the feature request.


--
Mike Lindsey

--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Feature request: Abstract ManyToManyField

2011-02-06 Thread Simon Meers
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
> > doing it wrong" if they come with advice on how to fix my problem,
> > without losing the easy Admin insertion of the relationships (without
> > resorting to InLines, which don't seem to play nicely at all with
> > FieldSets).  Right now I'm getting around the problem by running
> > syncdb, running dbshell to drop the table it complains about, and
> > rerunning syncdb; repeating until syncdb finishes successfully.
> >
> > What would make this exceptionally easy, is if there was the option to
> > set 'abstract=True' on second iteration of each of the
> > ManyToManyFields, telling syncdb to not attempt to create it.
>
> So what you're trying to do here is simply not supported. I'm guessing
> you've already concluded as much. This means that, for now, there is
> no good answer for you (that I'm aware of). Whatever hack or
> workaround you are able to come up with is what you're gonna get.
> Sorry.

BTW the ticket for this is #897 [1] and there is a suggested
workaround (explicit declaration of the 'through' table) which isn't
*too* ugly and might help you in the short-term?

Simon

[1] http://code.djangoproject.com/ticket/897

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Feature request: Abstract ManyToManyField

2011-02-14 Thread Peter


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 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 Admin insertion of the relationships (without
> > > resorting to InLines, which don't seem to play nicely at all with
> > > FieldSets).  Right now I'm getting around the problem by running
> > > syncdb, running dbshell to drop the table it complains about, and
> > > rerunning syncdb; repeating until syncdb finishes successfully.
>
> > > What would make this exceptionally easy, is if there was the option to
> > > set 'abstract=True' on second iteration of each of the
> > > ManyToManyFields, telling syncdb to not attempt to create it.
>
> > So what you're trying to do here is simply not supported. I'm guessing
> > you've already concluded as much. This means that, for now, there is
> > no good answer for you (that I'm aware of). Whatever hack or
> > workaround you are able to come up with is what you're gonna get.
> > Sorry.
>
> BTW the ticket for this is #897 [1] and there is a suggested
> workaround (explicit declaration of the 'through' table) which isn't
> *too* ugly and might help you in the short-term?
>
> Simon
>
> [1]http://code.djangoproject.com/ticket/897

Forgive me if I've missed the point (I didn't read the thread very
thoroughly) but does this snippet fit the bill?

http://djangosnippets.org/snippets/1295/

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.