Inverse Relationship

May 25, 2009 at 9:23 AM

EUSS do not seem to support inverse relationship; i mean when you have a one-to-many association between, for instance, a client and his invoices, when i add an invoice to a client : myClient.Invoices.Add(myNewInvoice), does myNewInvoice.Client equal to myClient automatically ?

Will this feature be embedded in a next version ? If so, when this new version will be released ?

 

Regards,

Coordinator
May 25, 2009 at 9:40 AM

This will never be done in an ORM in my opinion, as it's far more complex than stated. Yes you can map different "references" to each end of the relationship, using two mapping rules, but at the object level they will not be synchronized. This points the issue of OOP languages which lack Relationship concept, as of the UML notation for instance.

I've tried to explain this mismatch in one article (in French, google for "reification relations"), and to suggest a solution.

 

May 25, 2009 at 12:25 PM

Very interesting article. I never noticed this lack; i just know how to work around; it is good to come back to fundamentals :)

There is some ORM that provide integrity for this relationship concept : Entity Framework, XPO and (not tested) OpenAccess; Why it will not be possible with a great Persistence Layer like EUSS ?

EUSS generates proxies for properties and collections; The proxified properties can do the job : retrieve from an in-process second level cache or the attached session the entities needed to create the association ? This becomes a graph resolution that get its rules inside the mapping file ?

Does i miss something ?

 

Developer
May 25, 2009 at 12:41 PM

Considering Euss's capability to store objects in a memoryprovider, xml, simpledb (and maybe esent one day) it is not a mere mapping-issue. The metadata issue is of greater concern. XPO solves this by using attributes on the properties (the "many" property and the "one" property), but XPO and Entity Framework, as far as I know, does not seperate the concerns of telling what to persist and how to map it (if persisting to a relational store).

The mentioned approach using the proxified properties would be a viable solution, in my eyes. It would be necessary to provide metadata beyond the auto-generated metadata for Euss to know what to do.

May 25, 2009 at 12:55 PM
Edited May 25, 2009 at 12:55 PM

I have praticed XPO over 5 years and EF in a real project this year. I think EUSS opens new possibility. If there is a wish list where i can post my feature...

XPO indeed do not separate the both side : what you persist is what you map (there are TypeConverter but you cannot manage complex mapping)

But Entity Framework has these layers seperated : you have the conceptual model (OOP), the storage model (the database) and the mapping model (bridge between the both)

At this moment we have a preference for EUSS : the multiple storage layers, the simplicity, and the power;

Thank for your (quick) answers.

Developer
May 25, 2009 at 1:04 PM

Hi. I think the idea was to use the Issue Tracker on codeplex (http://euss.codeplex.com/WorkItem/List.aspx) for request tracking.

I’ve been using XPO in production for several years too. I think Euss’s strength lies in the ERA-pattern. Far ahead of XPO’s mapping=persistence, if you ask me.

Fra: PlasmaSoft [mailto:notifications@codeplex.com]
Sendt: 25. mai 2009 13:55
Til: Bjarte Skogøy
Emne: Re: Inverse Relationship [euss:57352]

From: PlasmaSoft

I have praticed XPO over 5 years and EF in a real project this year. I think EUSS opens new possibility. If there is a wish list where i can post my feature...

XPO indeed do not separate the both side : what you persist is what you map (there are TypeConverter but you cannot manage complex mapping)

But Entity Framework has these layers seperated : you have the conceptual model (OOP), the storage model (the database) and the mapping model (bridge between the both)

At this moment we have a preference for EUSS : the multiple storage layers, the simplicity, and the power;

Thank for your (quick) answers.

On Mon, May 25, 2009 at 1:41 PM, bjarte <notifications@codeplex.com> wrote:

From: bjarte

Considering Euss's capability to store objects in a memoryprovider, xml, simpledb (and maybe esent one day) it is not a mere mapping-issue. The metadata issue is of greater concern. XPO solves this by using attributes on the properties (the "many" property and the "one" property), but XPO and Entity Framework, as far as I know, does not seperate the concerns of telling what to persist and how to map it (if persisting to a relational store).

The mentioned approach using the proxified properties would be a viable solution, in my eyes. It would be necessary to provide metadata beyond the auto-generated metadata for Euss to know what to do.

Read the full discussion online.

To add a post to this discussion, reply to this email (euss@discussions.codeplex.com)

To start a new discussion for this project, email euss@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Read the full discussion online.

To add a post to this discussion, reply to this email (euss@discussions.codeplex.com)

To start a new discussion for this project, email euss@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

May 25, 2009 at 1:16 PM
Indeed; It is what i mean by the "simplicity" term; 

Again, many thanks for this exchange and your point of view.


Coordinator
May 25, 2009 at 1:51 PM

The inverse relationship could be handle for any kind of storage as we have the "relationship" in the metadata; with both sides of it. But we will never synchronize the two collections, like adding an instance to one side attaches ot tp the other end of the relationship. Though, you could work with both sides, wathever you choose. I think EF has the same behavior.

You can currently do it with the mapper by defining two mappings. But only with this one currently, if should be handled at the Core and Object levels if we wanted it for every engine. Something we will investigate.