Rails - Sep 2005 - :has_one and reverse dependencies? Also.. multiple associations?

Hi all,

I''m fairly new to rails, but am well versed in web applications. After
going
through AWDwR, I managed to get my first rails app banged out and in 
production. I''m now enthusiastically working on #2, but I''m
running into
some problems with my schema that I can''t quite wrap my head around. I
think
I''m going to have trouble explaining this, so please bear with me.

Part 1:

Let''s say I have the following models described briefly:

group: id, name, ... (has_many members, has_many events, has_many images)
members : id, group_id, image_id, name, ... (belongs_to group, belongs_to 
image)
images: id, group_id, content_type, ... (belongs_to group)
events: id, group_id, image_id, date, description, ... (belongs_to group, 
belongs_to image)

Now I know the typical practice would be to say that a ''member has_one 
image'' - but as you can see, I want both members and events to have 
associated images - and following DRY principles, I don''t want to
create
member_images, event_images models etc. since all images are basically going 
to hold the same data. That seems reasonable, right?

I was having a lot of trouble justifying the ''member belongs_to
image'' since
it isn''t true. Then, I reread the activerecord chapter and got to the
part
that suggests that you can think of ''belongs_to'' as
''references'' if it makes
you feel better. And that made me feel better. But now that I am further 
along in the application, I am running into trouble with my schema / models.

I would like to be able to delete an associated image when I delete the 
member or event, but using ''dependent'' in the model definition
doesn''t quite
solve this problem for me because according to rails, images is a parent of 
members and patricide is unacceptable (the relationship is reversed). I 
could do the deletion chain manually of course, but things would get ugly, 
and I''m sure a rails app shouldn''t be ugly in this way.

So please tell me - am I missing something? How could this be handled? Is my 
schema just unreasonable and I should just create separate *_images tables 
that are children of *? Should I not be using ''belongs_to'' for
this
situation? I think I hurt my brain several times trying to think out the 
flow of the relationships above. It totally works for me as SQL, but when I 
try to bring it over to a rails model it gets fuddled.

Part 2:

Let''s say that I want an image to belong_to both a group and a gallery
- I
don''t know why. Let''s say that an image can optionally be in a
gallery but
must always be associated with a group. What would be the best way to 
represent this in ruby? Right now I am doing something like the following 
with my members and their image parents:

member = Member.new( params[:member] )
image = Image.new( params[:image] )
group.images << image
member.image = image
group.members << member

I would probably do something similar to associate an image with a gallery 
and a group later on - is there a prettier and more official way of doing 
this? Say passing the associated id''s (group_id, gallery_id) on with
the
Image.new creation parameters? Would that be worse?

Sorry for stacking questions in the same mail. I think they''re sort of 
related though. Maybe.

Thanks in advance for any advice you can give. I just need a few pointers in 
the right direction.

-Pawel


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Hello, I''m not sure if I get all your questions right, but
I''ll try to
explain in your text what is my solution for problems like this ;-).
Hope it helps. Not guru :-D.

On 9/4/05, Pawel Szymczykowski
<makenai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Hi all,
>  
>  I''m fairly new to rails, but am well versed in web applications.
After
> going through AWDwR, I managed to get my first rails app banged out and in
> production. I''m now enthusiastically working on #2, but
I''m running into
> some problems with my schema that I can''t quite wrap my head
around. I think
> I''m going to have trouble explaining this, so please bear with me.
>  
>  Part 1:
>  
>  Let''s say I have the following models described briefly:
>  
>  group: id, name, ... (has_many members, has_many events, has_many images)
>  members : id, group_id, image_id, name, ... (belongs_to group, belongs_to
> image)
>  images: id, group_id, content_type, ... (belongs_to group)
>  events: id, group_id, image_id, date, description, ... (belongs_to group,
> belongs_to image)
>  
>  Now I know the typical practice would be to say that a ''member
has_one
> image'' - but as you can see, I want both members and events to
have
> associated images - and following DRY principles, I don''t want to
create
> member_images, event_images models etc. since all images are basically
going
> to hold the same data. That seems reasonable, right?
Can''t see any problem here. Just add this relation to both of them.
Maybe I''m missing something. For cases you need some special behaviour
for related classes (like validations for member image and event image
is different), create classes which are inherited to Image class like
EventImage << Image (look to documentation on ActiveRecord and
inheritance). Hope it''s understandable :-)

Also why do you have group has_many images relation? It''s group own
array or array collected from it''s members? If later I found in rails
better way to collect them from members.

Maybe send me offlist some more indepth look at your system, I''m not
sure I''m getting it right :-).
>  
>  I was having a lot of trouble justifying the ''member belongs_to
image''
> since it isn''t true. Then, I reread the activerecord chapter and
got to the
> part that suggests that you can think of ''belongs_to'' as
''references'' if it
> makes you feel better. And that made me feel better. But now that I am
> further along in the application, I am running into trouble with my schema
/
> models.
>  
>  I would like to be able to delete an associated image when I delete the
> member or event, but using ''dependent'' in the model
definition doesn''t quite
> solve this problem for me because according to rails, images is a parent of
> members and patricide is unacceptable (the relationship is reversed). I
> could do the deletion chain manually of course, but things would get ugly,
> and I''m sure a rails app shouldn''t be ugly in this way.
For me the best way when doing something more complicated like this is
in before_destroy callback.
>  
>  So please tell me - am I missing something? How could this be handled? Is
> my schema just unreasonable and I should just create separate *_images
> tables that are children of *? Should I not be using
''belongs_to'' for this
> situation? I think I hurt my brain several times trying to think out the
> flow of the relationships above. It totally works for me as SQL, but when I
> try to bring it over to a rails model it gets fuddled.
>  
>  Part 2:
>  
>  Let''s say that I want an image to belong_to both a group and a
gallery - I
> don''t know why. Let''s say that an image can optionally be
in a gallery but
> must always be associated with a group. What would be the best way to
> represent this in ruby? Right now I am doing something like the following
> with my members and their image parents:
>  
>      member = Member.new( params[:member] )
>      image  = Image.new( params[:image] )
>      group.images << image
>      member.image = image
>      group.members << member
>  
>  I would probably do something similar to associate an image with a gallery
> and a group later on - is there a prettier and more official way of doing
> this? Say passing the associated id''s (group_id, gallery_id) on
with the
> Image.new creation parameters? Would that be worse?
>  
>  Sorry for stacking questions in the same mail. I think they''re
sort of
> related though. Maybe.
I''m using this way often and can''t see anything wrong with it,
it''s
more comprehensive than passing ids (which is also possible just add
''group_id'' => group.id to @params. Good way is also to use
build_association and create_association methods.
>  
>  Thanks in advance for any advice you can give. I just need a few pointers
> in the right direction.
>  
>  -Pawel
>  
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 
> 
>

On 9/4/05, pepe <damn.pepe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 
> Hello, I''m not sure if I get all your questions right, but
I''ll try to
> explain in your text what is my solution for problems like this ;-).
> Hope it helps. Not guru :-D.

Thanks for the reply. :)

On 9/4/05, Pawel Szymczykowski
<makenai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> > Hi all,
> >
> > I''m fairly new to rails, but am well versed in web
applications. After
> > going through AWDwR, I managed to get my first rails app banged out
and
> in
> > production. I''m now enthusiastically working on #2, but
I''m running into
> > some problems with my schema that I can''t quite wrap my head
around. I
> think
> > I''m going to have trouble explaining this, so please bear
with me.
> >
> > Part 1:
> >
> > Let''s say I have the following models described briefly:
> >
> > group: id, name, ... (has_many members, has_many events, has_many 
> images)
> > members : id, group_id, image_id, name, ... (belongs_to group, 
> belongs_to
> > image)
> > images: id, group_id, content_type, ... (belongs_to group)
> > events: id, group_id, image_id, date, description, ... (belongs_to 
> group,
> > belongs_to image)
> >
> > Now I know the typical practice would be to say that a
''member has_one
> > image'' - but as you can see, I want both members and events
to have
> > associated images - and following DRY principles, I don''t
want to create
> > member_images, event_images models etc. since all images are basically
> going
> > to hold the same data. That seems reasonable, right?
> 
> Can''t see any problem here. Just add this relation to both of
them.
> Maybe I''m missing something. For cases you need some special
behaviour
> for related classes (like validations for member image and event image
> is different), create classes which are inherited to Image class like
> EventImage << Image (look to documentation on ActiveRecord and
> inheritance). Hope it''s understandable :-)
> 
> Also why do you have group has_many images relation? It''s group
own
> array or array collected from it''s members? If later I found in
rails
> better way to collect them from members.

It was my original idea that if an image was removed from a gallery or 
''detached'' from a user that it would still be available to
other members of
the group (via group_id) so that the images could still be browser, move to 
a gallery or deleted. But in retrospect, this is a little bit complicated 
and redundant - so I will probably just take it out. 

Maybe send me offlist some more indepth look at your system, I''m
not
> sure I''m getting it right :-).
> 
> >
> > I was having a lot of trouble justifying the ''member
belongs_to image''
> > since it isn''t true. Then, I reread the activerecord chapter
and got to
> the
> > part that suggests that you can think of
''belongs_to'' as ''references'' if
> it
> > makes you feel better. And that made me feel better. But now that I am
> > further along in the application, I am running into trouble with my 
> schema /
> > models.
> >
> > I would like to be able to delete an associated image when I delete
the
> > member or event, but using ''dependent'' in the model
definition doesn''t
> quite
> > solve this problem for me because according to rails, images is a
parent
> of
> > members and patricide is unacceptable (the relationship is reversed).
I
> > could do the deletion chain manually of course, but things would get 
> ugly,
> > and I''m sure a rails app shouldn''t be ugly in this
way.
> 
> For me the best way when doing something more complicated like this is
> in before_destroy callback.

Yeah, this makes sense to me. I guess I''m still bothered by how
''belongs_to''
makes things look. By the way, is it ok to have a relationship on only one 
side? Like above I have member belongs_to group, but image does not have_one 
member - is this legal? I thought I wouldn''t need to look up the member
from
the image since I''m not sure if it''s belongs to a member,
event or whatever
else has images. I''ll try doing with by subclassing. The section on
single
table inheritance caught my eye.
> So please tell me - am I missing something? How could this be handled? Is
> > my schema just unreasonable and I should just create separate *_images
> > tables that are children of *? Should I not be using
''belongs_to'' for
> this
> > situation? I think I hurt my brain several times trying to think out
the
> > flow of the relationships above. It totally works for me as SQL, but 
> when I
> > try to bring it over to a rails model it gets fuddled.
> >
> > Part 2:
> >
> > Let''s say that I want an image to belong_to both a group and
a gallery -
> I
> > don''t know why. Let''s say that an image can
optionally be in a gallery
> but
> > must always be associated with a group. What would be the best way to
> > represent this in ruby? Right now I am doing something like the 
> following
> > with my members and their image parents:
> >
> > member = Member.new( params[:member] )
> > image = Image.new( params[:image] )
> > group.images << image
> > member.image = image
> > group.members << member
> >
> > I would probably do something similar to associate an image with a 
> gallery
> > and a group later on - is there a prettier and more official way of 
> doing
> > this? Say passing the associated id''s (group_id, gallery_id)
on with the
> > Image.new creation parameters? Would that be worse?
> >
> > Sorry for stacking questions in the same mail. I think
they''re sort of
> > related though. Maybe.
> 
> I''m using this way often and can''t see anything wrong
with it, it''s
> more comprehensive than passing ids (which is also possible just add
> ''group_id'' => group.id <http://group.id> to
@params. Good way is also to
> use
> build_association and create_association methods.

I overlooked these in my reading, but I''m going to look into them now. 
Thanks!
> Thanks in advance for any advice you can give. I just need a few pointers
> > in the right direction.
> >
> > -Pawel
> >
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> >
> >
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

I think what''d be REALLy cool is commonly solved problem domains...  
for free...

In other words, when a railser has written some code which solves a  
certain problem domain, he submits it to a certain respository...  
therefore we all share in a mind-share of common code and all have to  
write that code less and less.

jules.

On 04/09/2005, at 8:07 PM, Pawel Szymczykowski wrote:
> Hi all,
>
> I''m fairly new to rails, but am well versed in web applications.  
> After going through AWDwR, I managed to get my first rails app  
> banged out and in production. I''m now enthusiastically working on
> #2, but I''m running into some problems with my schema that I
can''t
> quite wrap my head around. I think I''m going to have trouble  
> explaining this, so please bear with me.
>
> Part 1:
>
> Let''s say I have the following models described briefly:
>
> group: id, name, ... (has_many members, has_many events, has_many  
> images)
> members : id, group_id, image_id, name, ... (belongs_to group,  
> belongs_to image)
> images: id, group_id, content_type, ... (belongs_to group)
> events: id, group_id, image_id, date, description, ... (belongs_to  
> group, belongs_to image)
>
> Now I know the typical practice would be to say that a ''member  
> has_one image'' - but as you can see, I want both members and
events
> to have associated images - and following DRY principles, I don''t
> want to create member_images, event_images models etc. since all  
> images are basically going to hold the same data. That seems  
> reasonable, right?
>
> I was having a lot of trouble justifying the ''member belongs_to  
> image'' since it isn''t true. Then, I reread the
activerecord chapter
> and got to the part that suggests that you can think of  
> ''belongs_to'' as ''references'' if it
makes you feel better. And that
> made me feel better. But now that I am further along in the  
> application, I am running into trouble with my schema / models.
>
> I would like to be able to delete an associated image when I delete  
> the member or event, but using ''dependent'' in the model
definition
> doesn''t quite solve this problem for me because according to
rails,
> images is a parent of members and patricide is unacceptable (the  
> relationship is reversed). I could do the deletion chain manually  
> of course, but things would get ugly, and I''m sure a rails app  
> shouldn''t be ugly in this way.
>
> So please tell me - am I missing something? How could this be  
> handled? Is my schema just unreasonable and I should just create  
> separate *_images tables that are children of *? Should I not be  
> using ''belongs_to'' for this situation? I think I hurt my
brain
> several times trying to think out the flow of the relationships  
> above. It totally works for me as SQL, but when I try to bring it  
> over to a rails model it gets fuddled.
>
> Part 2:
>
> Let''s say that I want an image to belong_to both a group and a  
> gallery - I don''t know why. Let''s say that an image can
optionally
> be in a gallery but must always be associated with a group. What  
> would be the best way to represent this in ruby? Right now I am  
> doing something like the following with my members and their image  
> parents:
>
>     member = Member.new( params[:member] )
>     image  = Image.new( params[:image] )
>     group.images << image
>     member.image = image
>     group.members << member
>
> I would probably do something similar to associate an image with a  
> gallery and a group later on - is there a prettier and more  
> official way of doing this? Say passing the associated id''s  
> (group_id, gallery_id) on with the Image.new creation parameters?  
> Would that be worse?
>
> Sorry for stacking questions in the same mail. I think they''re
sort
> of related though. Maybe.
>
> Thanks in advance for any advice you can give. I just need a few  
> pointers in the right direction.
>
> -Pawel
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Oct 4, 2005, at 7:52 AM, Julian Leviston wrote:
> I think what''d be REALLy cool is commonly solved problem
domains...
> for free...
>
> In other words, when a railser has written some code which solves a  
> certain problem domain, he submits it to a certain respository...  
> therefore we all share in a mind-share of common code and all have  
> to write that code less and less.
Jules, that''s a great idea.  How about starting some pages on the  
wiki with a special category?  e.g. ProblemDomain or DomainModel.

Best,
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDQqrZAQHALep9HFYRAhMBAJ49J0yQGCM4zPSEAwmTwmFu+VuDOQCgvoex
lG5GNwWSqbM4KuhaPNsL57s=+MXp
-----END PGP SIGNATURE-----