GLORP

useLinkTable just tells the mapping that it ought to use a link table. It won't automatically define it.

If you have a link table defined, and the foreign key constraints set up appropriately, and it's all unambiguous (e.g. you don't have two different relationships from this table using the same link table) then Glorp will probably manage to figure out that it ought to use a link table, and what the join ought to be, automatically.

At 10:41 AM 7/27/2006, Martin J. Laubach wrote:
>  What is the difference between one having
>
>        (aDescriptor newMapping: ManyToManyMapping)
>                attributeName: #members;
>                useLinkTable;
>                join: (Join ...)
>
>  and just having
>
>        (aDescriptor newMapping: ManyToManyMapping)
>                attributeName: #members
>
>  and manually defining a tableForMYLINKTABLE with appropriate foreign
>key constraints? Is there some basic difference or does #useLinkTable
>just magically do the table definition for me?
>
>        mjl
>
>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Glorp-development mailing list
>Glorp-development@...
>https://lists.sourceforge.net/lists/listinfo/glorp-development

--
Alan Knight [|], Cincom Smalltalk Development
knight@...
aknight@...
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

|  If you have a link table defined, and the foreign key constraints
| set up appropriately, and it's all unambiguous (e.g. you don't have
| two different relationships from this table using the same link table)
| then Glorp will probably manage to figure out that it ought to use a
| link table, and what the join ought to be, automatically.

  Indeed it does (did I mention that Glorp is pretty amazing?). That's
why I'm wondering what the useLinkTable is about.

  I can see that one might to use join: ... to define exactly how
to get at the information, but what is useLinkTable for?

	mjl

At 12:08 PM 7/27/2006, Martin J. Laubach wrote:
>|  If you have a link table defined, and the foreign key constraints
>| set up appropriately, and it's all unambiguous (e.g. you don't have
>| two different relationships from this table using the same link table)
>| then Glorp will probably manage to figure out that it ought to use a
>| link table, and what the join ought to be, automatically.
>
>  Indeed it does (did I mention that Glorp is pretty amazing?). That's
>why I'm wondering what the useLinkTable is about.
>
>  I can see that one might to use join: ... to define exactly how
>to get at the information, but what is useLinkTable for?

Well, it tells Glorp whether or not there's a link table in use, which makes it do a number of things differently. For one thing, we always want to cascade delete of link table rows. Obviously we construct the query differently. Internally there's some interesting stuff to do with what object owns a row and RowMapKeys, but if you don't have to worry about that you probably don't want to :-)

And it looks to me like it won't figure out whether or not there's a link table automatically. If it knows whether or not you're using a link table, it will get the join, but it has to be told if there's a link table or else it will just assume that the link table is the target, and get confused.

--
Alan Knight [|], Cincom Smalltalk Development
knight@...
aknight@...
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Okay now I get it.

  One more related question: if I have an N:M relationship (ie.
there is a link table), can/should one model that relationship
as Collections on both sides or will that give me terrible
inconsistencies with in-core objects and shred the dog?

	mjl

You can model it that way with no problem, the only worry is that you are responsible for maintaining the consistency of those collections, just as you would be if they weren't persistent. So if you add something to one side, you need to make sure you add the corresponding entry to the other side.

At 01:19 AM 7/28/2006, Martin J. Laubach wrote:
>  Okay now I get it.
>
>  One more related question: if I have an N:M relationship (ie.
>there is a link table), can/should one model that relationship
>as Collections on both sides or will that give me terrible
>inconsistencies with in-core objects and shred the dog?
>
>        mjl
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Glorp-development mailing list
>Glorp-development@...
>https://lists.sourceforge.net/lists/listinfo/glorp-development

--
Alan Knight [|], Cincom Smalltalk Development
knight@...
aknight@...
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross