Re: EOModel needs an easy tweak

2010-11-07 Thread Farrukh Ijaz
Hi Mark,

Thanks for the detailed explanation. Comments below:

On 2010-11-06, at 10:35 PM, Mark Wardle wrote:

 Hi Farrukh,
 
 I'm no expert on these matters but unless I have a very simple and
 straightforward plan of inheritance that would be immediately obvious
 to someone else joining the project, I've avoiding using EOF
 inheritance. I've dabbled with a number of options depending on the
 exact circumstances and most importantly, what has the *correct
 real-life semantic*.
 
 For instance, I've used enums to represent behaviours and have linked
 these to behaviour classes - the enterprise objects can simply call
 its registered behaviour object.method - I'm basing this on posts to
 the list from Ramsey.

Can you please explain a little bit more on this?

 
 In other situations, I've simply used java interfaces and implement
 these within separate entities perhaps factoring out common
 functionality into a helper class.
 
 For your case, I'm finding it difficult to imagine why two entities
 (IS-A) have such different relationship requirements.

The model has a legacy. In the beginning the entities appear to be different 
but semantically they are have some common behaviour when observed under 
specific domain . E.g. in a File System we have File and Folder (Directory) two 
separate entities. But at OS level, both have name, timestamp, permissions etc. 
The need before was to treat File and Folder as separate entities, but now the 
requirement demands to have some granularity among them. This is just an 
example to explain the situation.

 If you really
 need to do this and want to use EOF inheritance, then perhaps you can
 have two trees of inheritance. The first tree would have Entity X as
 root. These entities would defer handling of relationships to one of
 two entities that provide the appropriate relationship behaviour  -
 to-one or to-many.

My domain knowledge is limited so I may need further explanation here too.

Farrukh

 
 Good luck,
 
 Mark
 
 On 6 November 2010 11:39, Farrukh Ijaz
 farrukh.i...@fuegodigitalmedia.com wrote:
 Hi EOF-ologists,
 
 I've a modelling issue and need to know what could be the suitable fix (or 
 tweak) to fulfil the requirement.
 
 Below is the existing EO Model.
 
 
 I've two entities (Entity A and Entity B) extending Abstract Entity X but 
 these entities have their own tables (no single table inheritance). I need 
 to design Entity D and Entity E where Entity D has a toMany relationship 
 with Entity E and Entity E needs to have a toOne relationship with Entity A, 
 Entity B, Entity C and Entity D.
 
 1. One way can be for Entity E to have four different relationships such as 
 toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable)
 2. The other way mentioned in the lower diagram where Entity A, Entity B, 
 Entity C and Entity D extend Abstract Entity X and Entity E will have toOne 
 relationship with Abstract Entity X. (This is _desirable_).
 
 
 What would be the easiest way to model such relationship? I'm _not_ 
 relationship expert so may be the way I assumed the model (second diagram) 
 can be wrong or practically impossible?
 Also note that I cannot make Entity C and Entity D to extend Abstract Entity 
 X due to some design constraints therefore I think to introduce Abstract 
 Entity Alpha.
 
 Thanks,
 
 Farrukh
 
 
 
 
  ___
 Do not post admin requests to the list. They will be ignored.
 Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org
 
 This email sent to m...@wardle.org
 
 
 
 
 -- 
 Dr. Mark Wardle
 Specialist registrar, Neurology
 Cardiff, UK
 ___
 Do not post admin requests to the list. They will be ignored.
 Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/webobjects-dev/farrukh.ijaz%40fuegodigitalmedia.com
 
 This email sent to farrukh.i...@fuegodigitalmedia.com

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: EOModel needs an easy tweak

2010-11-07 Thread Chuck Hill
On Nov 6, 2010, at 11:02 PM, Farrukh Ijaz wrote:

 For your case, I'm finding it difficult to imagine why two entities
 (IS-A) have such different relationship requirements.
 
 The model has a legacy. In the beginning the entities appear to be different 
 but semantically they are have some common behaviour when observed under 
 specific domain . E.g. in a File System we have File and Folder (Directory) 
 two separate entities. But at OS level, both have name, timestamp, 
 permissions etc. The need before was to treat File and Folder as separate 
 entities, but now the requirement demands to have some granularity among 
 them. This is just an example to explain the situation.


But do they share behavior?  Shared data is not necessarily an indication for 
inheritance.


Chuck

-- 
Chuck Hill Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall 
knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects









smime.p7s
Description: S/MIME cryptographic signature
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: EOModel needs an easy tweak

2010-11-07 Thread Farrukh Ijaz
Hi Chuck,

Thanks for your input and I hope it will help me understand the EOF 
relationship modelling better. Comments below:

On 2010-11-07, at 8:35 PM, Chuck Hill wrote:

 On Nov 6, 2010, at 11:02 PM, Farrukh Ijaz wrote:
 
 For your case, I'm finding it difficult to imagine why two entities
 (IS-A) have such different relationship requirements.
 
 The model has a legacy. In the beginning the entities appear to be different 
 but semantically they are have some common behaviour when observed under 
 specific domain . E.g. in a File System we have File and Folder (Directory) 
 two separate entities. But at OS level, both have name, timestamp, 
 permissions etc. The need before was to treat File and Folder as separate 
 entities, but now the requirement demands to have some granularity among 
 them. This is just an example to explain the situation.
 
 
 But do they share behavior?  Shared data is not necessarily an indication for 
 inheritance.

I can't answer this with 100% accuracy. But let me try to explain the model 
using Unix file system so it could become clear whether they share behaviour or 
not.

In Unix (or Linux) I can create directories (Entity A), and files (Entity B). 
Directories can have subdirectories and files (Entity A - toMany Entity A and 
Entity A - toMany Entity B). Now I have a requirement where I need to have a 
special type of directory (Entity C) which can have symlinks (Entity D) or 
subdirectories of  it's own type (Entity C) which means Entity C - toMany 
Entity C and Entity C - toMany Entity D. Each symlink can only point to 
directory, file, special directory or another symlink (which means Entity D - 
toOne Entity A or toOne Entity B or toOne Entity C or toOne Entity D).

In this situation, if need an abstraction (either based on java based interface 
or EOF inheritance) which could treat all Entity A, Entity B, Entity C and 
Entity D such as Entity Alpha so I could have only 1 toOne relationship from 
Entity D to Entity Alpha.

My assumption is, if I implement a Java interface instead of EOF inheritance, 
EOF won't help much and I need to manage this relationship programmatically, 
right?

If the explanation is still confusing then I would opt for four toOne 
relationships from Entity D - Entity A, Entity B, Entity C and Entity D. 
Assign all of them an interface to collect common data provide additional 
method to return a common object (by inspecting all of the four relationships 
as only 1 will be present at a time).

Farrukh ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: EOModel needs an easy tweak

2010-11-06 Thread Steve Peery
Is there any shared functionality between Entity A, Entity B, Entity C and 
Entity D that would justify Abstract Entity Alpha?

Steve

On Nov 6, 2010, at 7:39 AM, Farrukh Ijaz wrote:

 Hi EOF-ologists,
 
 I've a modelling issue and need to know what could be the suitable fix (or 
 tweak) to fulfil the requirement.
 
 Below is the existing EO Model.
 Existing.png
 I've two entities (Entity A and Entity B) extending Abstract Entity X but 
 these entities have their own tables (no single table inheritance). I need to 
 design Entity D and Entity E where Entity D has a toMany relationship with 
 Entity E and Entity E needs to have a toOne relationship with Entity A, 
 Entity B, Entity C and Entity D. 
 
 1. One way can be for Entity E to have four different relationships such as 
 toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable)
 2. The other way mentioned in the lower diagram where Entity A, Entity B, 
 Entity C and Entity D extend Abstract Entity X and Entity E will have toOne 
 relationship with Abstract Entity X. (This is _desirable_).
 Desired.png
 What would be the easiest way to model such relationship? I'm _not_ 
 relationship expert so may be the way I assumed the model (second diagram) 
 can be wrong or practically impossible? 
 Also note that I cannot make Entity C and Entity D to extend Abstract Entity 
 X due to some design constraints therefore I think to introduce Abstract 
 Entity Alpha.
 
 Thanks,
 
 Farrukh
 
 
 
 ___
 Do not post admin requests to the list. They will be ignored.
 Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com
 
 This email sent to spe...@me.com

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: EOModel needs an easy tweak

2010-11-06 Thread Jean-Francois Veillette
 2. The other way mentioned in the lower diagram where Entity A, Entity B, 
 Entity C and Entity D extend Abstract Entity X and Entity E will have toOne 
 relationship with Abstract Entity X. (This is _desirable_).

Not knowing anymore that that of your model, I would take the Entity Alpha 
option.
Take a look at ERXLongPrimaryKeyFactory in order to ease the fetching of that 
relationship (not to fetch many tables).

jfv


 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: EOModel needs an easy tweak

2010-11-06 Thread Mark Wardle
Hi Farrukh,

I'm no expert on these matters but unless I have a very simple and
straightforward plan of inheritance that would be immediately obvious
to someone else joining the project, I've avoiding using EOF
inheritance. I've dabbled with a number of options depending on the
exact circumstances and most importantly, what has the *correct
real-life semantic*.

For instance, I've used enums to represent behaviours and have linked
these to behaviour classes - the enterprise objects can simply call
its registered behaviour object.method - I'm basing this on posts to
the list from Ramsey.

In other situations, I've simply used java interfaces and implement
these within separate entities perhaps factoring out common
functionality into a helper class.

For your case, I'm finding it difficult to imagine why two entities
(IS-A) have such different relationship requirements. If you really
need to do this and want to use EOF inheritance, then perhaps you can
have two trees of inheritance. The first tree would have Entity X as
root. These entities would defer handling of relationships to one of
two entities that provide the appropriate relationship behaviour  -
to-one or to-many.

Good luck,

Mark

On 6 November 2010 11:39, Farrukh Ijaz
farrukh.i...@fuegodigitalmedia.com wrote:
 Hi EOF-ologists,

 I've a modelling issue and need to know what could be the suitable fix (or 
 tweak) to fulfil the requirement.

 Below is the existing EO Model.


 I've two entities (Entity A and Entity B) extending Abstract Entity X but 
 these entities have their own tables (no single table inheritance). I need to 
 design Entity D and Entity E where Entity D has a toMany relationship with 
 Entity E and Entity E needs to have a toOne relationship with Entity A, 
 Entity B, Entity C and Entity D.

 1. One way can be for Entity E to have four different relationships such as 
 toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable)
 2. The other way mentioned in the lower diagram where Entity A, Entity B, 
 Entity C and Entity D extend Abstract Entity X and Entity E will have toOne 
 relationship with Abstract Entity X. (This is _desirable_).


 What would be the easiest way to model such relationship? I'm _not_ 
 relationship expert so may be the way I assumed the model (second diagram) 
 can be wrong or practically impossible?
 Also note that I cannot make Entity C and Entity D to extend Abstract Entity 
 X due to some design constraints therefore I think to introduce Abstract 
 Entity Alpha.

 Thanks,

 Farrukh




  ___
 Do not post admin requests to the list. They will be ignored.
 Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org

 This email sent to m...@wardle.org




-- 
Dr. Mark Wardle
Specialist registrar, Neurology
Cardiff, UK
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: EOModel needs an easy tweak

2010-11-06 Thread Farrukh Ijaz
Yes, they will expose certain properties which are symmetrical in all the 
entities, e.g. title, description, etc. 

Consider this requirement as a tree structure which can have nodes that appear 
to be symmetric but their underlying user object can be different.

Farrukh 

Sent from my iPhone

On 2010-11-06, at 9:58 PM, Steve Peery spe...@me.com wrote:

 Is there any shared functionality between Entity A, Entity B, Entity C and 
 Entity D that would justify Abstract Entity Alpha?
 
 Steve
 
 On Nov 6, 2010, at 7:39 AM, Farrukh Ijaz wrote:
 
 Hi EOF-ologists,
 
 I've a modelling issue and need to know what could be the suitable fix (or 
 tweak) to fulfil the requirement.
 
 Below is the existing EO Model.
 Existing.png
 I've two entities (Entity A and Entity B) extending Abstract Entity X but 
 these entities have their own tables (no single table inheritance). I need 
 to design Entity D and Entity E where Entity D has a toMany relationship 
 with Entity E and Entity E needs to have a toOne relationship with Entity A, 
 Entity B, Entity C and Entity D. 
 
 1. One way can be for Entity E to have four different relationships such as 
 toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable)
 2. The other way mentioned in the lower diagram where Entity A, Entity B, 
 Entity C and Entity D extend Abstract Entity X and Entity E will have toOne 
 relationship with Abstract Entity X. (This is _desirable_).
 Desired.png
 What would be the easiest way to model such relationship? I'm _not_ 
 relationship expert so may be the way I assumed the model (second diagram) 
 can be wrong or practically impossible? 
 Also note that I cannot make Entity C and Entity D to extend Abstract Entity 
 X due to some design constraints therefore I think to introduce Abstract 
 Entity Alpha.
 
 Thanks,
 
 Farrukh
 
 
 
 ___
 Do not post admin requests to the list. They will be ignored.
 Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com
 
 This email sent to spe...@me.com
 
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: EOModel needs an easy tweak

2010-11-06 Thread Steve Peery
If that is the case, then your Abstract Entity Alpha scenario seems reasonable.

Steve

On Nov 6, 2010, at 3:23 PM, Farrukh Ijaz wrote:

 Yes, they will expose certain properties which are symmetrical in all the 
 entities, e.g. title, description, etc. 
 
 Consider this requirement as a tree structure which can have nodes that 
 appear to be symmetric but their underlying user object can be different.
 
 Farrukh 
 
 Sent from my iPhone
 
 On 2010-11-06, at 9:58 PM, Steve Peery spe...@me.com wrote:
 
 Is there any shared functionality between Entity A, Entity B, Entity C and 
 Entity D that would justify Abstract Entity Alpha?
 
 Steve
 
 On Nov 6, 2010, at 7:39 AM, Farrukh Ijaz wrote:
 
 Hi EOF-ologists,
 
 I've a modelling issue and need to know what could be the suitable fix (or 
 tweak) to fulfil the requirement.
 
 Below is the existing EO Model.
 Existing.png
 I've two entities (Entity A and Entity B) extending Abstract Entity X but 
 these entities have their own tables (no single table inheritance). I need 
 to design Entity D and Entity E where Entity D has a toMany relationship 
 with Entity E and Entity E needs to have a toOne relationship with Entity 
 A, Entity B, Entity C and Entity D. 
 
 1. One way can be for Entity E to have four different relationships such as 
 toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable)
 2. The other way mentioned in the lower diagram where Entity A, Entity B, 
 Entity C and Entity D extend Abstract Entity X and Entity E will have toOne 
 relationship with Abstract Entity X. (This is _desirable_).
 Desired.png
 What would be the easiest way to model such relationship? I'm _not_ 
 relationship expert so may be the way I assumed the model (second diagram) 
 can be wrong or practically impossible? 
 Also note that I cannot make Entity C and Entity D to extend Abstract 
 Entity X due to some design constraints therefore I think to introduce 
 Abstract Entity Alpha.
 
 Thanks,
 
 Farrukh
 
 
 
 ___
 Do not post admin requests to the list. They will be ignored.
 Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com
 
 This email sent to spe...@me.com
 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: EOModel needs an easy tweak

2010-11-06 Thread Chuck Hill
If all they share is a few common, generic attributes, I would not use 
inheritance for this.  I'd prefer an interface.  As Mark pointed out,  
inheritance is for IS A relationships.  It is not to save some implementation 
time.  That is an abuse of inheritance.  If they share behavior, then 
inheritance is more likely the correct design.

Barbara Liskov has some excellent articles on this.  Google for Liskov 
Substitution Principal.

Chuck


On Nov 6, 2010, at 12:23 PM, Farrukh Ijaz wrote:

 Yes, they will expose certain properties which are symmetrical in all the 
 entities, e.g. title, description, etc. 
 
 Consider this requirement as a tree structure which can have nodes that 
 appear to be symmetric but their underlying user object can be different.
 
 Farrukh 
 
 Sent from my iPhone
 
 On 2010-11-06, at 9:58 PM, Steve Peery spe...@me.com wrote:
 
 Is there any shared functionality between Entity A, Entity B, Entity C and 
 Entity D that would justify Abstract Entity Alpha?
 
 Steve
 
 On Nov 6, 2010, at 7:39 AM, Farrukh Ijaz wrote:
 
 Hi EOF-ologists,
 
 I've a modelling issue and need to know what could be the suitable fix (or 
 tweak) to fulfil the requirement.
 
 Below is the existing EO Model.
 Existing.png
 I've two entities (Entity A and Entity B) extending Abstract Entity X but 
 these entities have their own tables (no single table inheritance). I need 
 to design Entity D and Entity E where Entity D has a toMany relationship 
 with Entity E and Entity E needs to have a toOne relationship with Entity 
 A, Entity B, Entity C and Entity D. 
 
 1. One way can be for Entity E to have four different relationships such as 
 toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable)
 2. The other way mentioned in the lower diagram where Entity A, Entity B, 
 Entity C and Entity D extend Abstract Entity X and Entity E will have toOne 
 relationship with Abstract Entity X. (This is _desirable_).
 Desired.png
 What would be the easiest way to model such relationship? I'm _not_ 
 relationship expert so may be the way I assumed the model (second diagram) 
 can be wrong or practically impossible? 
 Also note that I cannot make Entity C and Entity D to extend Abstract 
 Entity X due to some design constraints therefore I think to introduce 
 Abstract Entity Alpha.
 
 Thanks,
 
 Farrukh
 
 
 
 ___
 Do not post admin requests to the list. They will be ignored.
 Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com
 
 This email sent to spe...@me.com
 
 ___
 Do not post admin requests to the list. They will be ignored.
 Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
 
 This email sent to ch...@global-village.net

-- 
Chuck Hill Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall 
knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects









smime.p7s
Description: S/MIME cryptographic signature
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: EOModel needs an easy tweak

2010-11-06 Thread Farrukh Ijaz
Hi Chuck,

All the entities (A, B, C, and D) eventually have become IS-A relationship. I 
would also like to use interface instead of inheritance but thinking how I can 
manage the Entity E to have toOne relationship for all these entities using 
interface. May be I need to write custom code to manage the storage and 
retrieval for this relationship? Any clue or reference to existing example 
would be helpful. 

Thanks,

Farrukh

Sent from my iPhone

On 2010-11-07, at 1:00 AM, Chuck Hill ch...@global-village.net wrote:

 If all they share is a few common, generic attributes, I would not use 
 inheritance for this.  I'd prefer an interface.  As Mark pointed out,  
 inheritance is for IS A relationships.  It is not to save some 
 implementation time.  That is an abuse of inheritance.  If they share 
 behavior, then inheritance is more likely the correct design.
 
 Barbara Liskov has some excellent articles on this.  Google for Liskov 
 Substitution Principal.
 
 Chuck
 
 
 On Nov 6, 2010, at 12:23 PM, Farrukh Ijaz wrote:
 
 Yes, they will expose certain properties which are symmetrical in all the 
 entities, e.g. title, description, etc. 
 
 Consider this requirement as a tree structure which can have nodes that 
 appear to be symmetric but their underlying user object can be different.
 
 Farrukh 
 
 Sent from my iPhone
 
 On 2010-11-06, at 9:58 PM, Steve Peery spe...@me.com wrote:
 
 Is there any shared functionality between Entity A, Entity B, Entity C and 
 Entity D that would justify Abstract Entity Alpha?
 
 Steve
 
 On Nov 6, 2010, at 7:39 AM, Farrukh Ijaz wrote:
 
 Hi EOF-ologists,
 
 I've a modelling issue and need to know what could be the suitable fix (or 
 tweak) to fulfil the requirement.
 
 Below is the existing EO Model.
 Existing.png
 I've two entities (Entity A and Entity B) extending Abstract Entity X but 
 these entities have their own tables (no single table inheritance). I need 
 to design Entity D and Entity E where Entity D has a toMany relationship 
 with Entity E and Entity E needs to have a toOne relationship with Entity 
 A, Entity B, Entity C and Entity D. 
 
 1. One way can be for Entity E to have four different relationships such 
 as toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable)
 2. The other way mentioned in the lower diagram where Entity A, Entity B, 
 Entity C and Entity D extend Abstract Entity X and Entity E will have 
 toOne relationship with Abstract Entity X. (This is _desirable_).
 Desired.png
 What would be the easiest way to model such relationship? I'm _not_ 
 relationship expert so may be the way I assumed the model (second diagram) 
 can be wrong or practically impossible? 
 Also note that I cannot make Entity C and Entity D to extend Abstract 
 Entity X due to some design constraints therefore I think to introduce 
 Abstract Entity Alpha.
 
 Thanks,
 
 Farrukh
 
 
 
 ___
 Do not post admin requests to the list. They will be ignored.
 Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com
 
 This email sent to spe...@me.com
 
 ___
 Do not post admin requests to the list. They will be ignored.
 Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
 
 This email sent to ch...@global-village.net
 
 -- 
 Chuck Hill Senior Consultant / VP Development
 
 Practical WebObjects - for developers who want to increase their overall 
 knowledge of WebObjects or who are trying to solve specific problems.
 http://www.global-village.net/products/practical_webobjects
 
 
 
 
 
 
 
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com