New Posts New Posts RSS Feed: MS EF Supports "Join Tables" that DevForce EF Does not
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

MS EF Supports "Join Tables" that DevForce EF Does not
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
ryanhaney View Drop Down
Newbie
Newbie


Joined: 20-Mar-2008
Location: United States
Posts: 15 		Post Options Post Options   Quote ryanhaney Quote  Post ReplyReply Direct Link To This Post Topic: MS EF Supports "Join Tables" that DevForce EF Does not
    Posted: 20-Mar-2008 at 7:13am

I have a database that has many tables that follow the same relationship structure:

Members (MemberID,First,Last,Username,Password)
Accounts (AccountID,Brand,Number)
MemberAccounts (MemberID,AccountID)
 
This scenario works in Microsoft EF - and all the objects are generated correctly - but I I cannot get generated code to compile in DevForce EF.
 
Thanks!
 
Ryan Haney
Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391 		Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Posted: 20-Mar-2008 at 11:08am
You're correct that many-many relationships are supported in EF but not (yet) in DEF.  At this time, to work around the issue you need to add "payload" to your join table.  "Payload" can be any additional column, and ensures that an Entity is created for the table, instead of just the association.
 
I'd like to say we'll address this in Beta2, but it looks like we probably won't get to this until 1st release at the earliest.  If it's a show stopper issue for you let us know, and we'll bump the priority. 
Back to Top
ryanhaney View Drop Down
Newbie
Newbie


Joined: 20-Mar-2008
Location: United States
Posts: 15 		Post Options Post Options   Quote ryanhaney Quote  Post ReplyReply Direct Link To This Post Posted: 20-Mar-2008 at 1:22pm
It is a show stopper for me - but I am still in evaluation mode.
Back to Top
ryanhaney View Drop Down
Newbie
Newbie


Joined: 20-Mar-2008
Location: United States
Posts: 15 		Post Options Post Options   Quote ryanhaney Quote  Post ReplyReply Direct Link To This Post Posted: 20-Mar-2008 at 8:28pm
FYI, I refactored my schema to not be so flexible - probably won't need all the many-to-many relationships anyways :-).
 
BUT, I CAN see the scenario - and I see v1 RTM support as necessary :-).
 
Code compiles now!
 
Time to have some fun!
Back to Top
philpastor View Drop Down
Newbie
Newbie
Avatar

Joined: 09-Apr-2008
Location: United States
Posts: 9 		Post Options Post Options   Quote philpastor Quote  Post ReplyReply Direct Link To This Post Posted: 09-Apr-2008 at 10:11am
Lack of a true "Association" is a show stopper for me as well ... although we are also still in evaluation mode.
Back to Top
AdamC View Drop Down
Newbie
Newbie
Avatar

Joined: 04-Feb-2008
Location: United States
Posts: 20 		Post Options Post Options   Quote AdamC Quote  Post ReplyReply Direct Link To This Post Posted: 29-Apr-2008 at 11:09am
We would also like to see many-to-many relationships in DEF.  We have an extremely large database (900+ tables) and would prefer not to add dozens of payload columns just to get the DEF code to compile.  I believe code generated by DevForce should at least compile unless the customer has done something out of the ordinary in the database.  Many-to-many relationships are very common and should probably be supported.
Back to Top
GregD View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 374 		Post Options Post Options   Quote GregD Quote  Post ReplyReply Direct Link To This Post Posted: 06-May-2008 at 1:12pm

Adam, Phil:

 

We hear you, and we're working on it. There are difficulties associated with information that Microsoft exposes (or doesn't) about foreign keys on its EntityObjects, and as the EF software is still itself in beta this is a moving target. Initially Microsoft didn't expose the foreign keys on *any* entities and enough developers complained that they began doing so.  And there are a whole special set of issues with the linking entities that the EF hides altogether. But we'll get it working, so stay tuned.

 

For those designing new databases, I'd like to make the case for always using a single-column, arbitrary primary key (which, from the EF's viewpoint, constitutes payload) in every table.  This solves the EF issues and is, I think, desirable for other reasons as well.  Eliminating the primary key style as a discriminator between linking and other tables gives you a nice flexibility to let the entities embodied in linking tables evolve into things that have significance in the own right (as does an Order that serves as the linking entity between Customers and SalesReps, Customers and Shippers, and SalesReps and Shippers.) You treat all entities the same way, as far as primary key is concerned, and a type can evolve as needed without causing you to change your style of working with it mid-stream.  In the EF, the distinction between how entities with and without payload are handled guarantees that you *will* have to change your strategy if a payload-free linking entity suddenly needs to be made richer.  I'd rather just allow for such evolution up front.

 

It's easy to code many-to-many navigation properties into your entities. Each such property takes a couple of lines of code (one line if you wish!). We could generate them, too, if we were to see sufficient demand for that. The problem there is that not all many-to-many relations defined in a database are necessarily significant from a business viewpoint, and we don't want to generate a lot of unnecessary stuff; so then we might need a UI to allow you to tell us which of the many many-to-manys you actually want. 8-) But it could certainly be done.

 

Greg Dunn

Training and Documentation Manager

IdeaBlade
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down