TargetMultiplicity ZeroOne

[alo]

I've created a domain model based on a database first scenario.  I have two tables that have a one to one relationship.  When I updated the model from the database, the model brings in the two tables and the relationship.  The relationship has its TargetMultiplicity set to ZeroMany.  This results in the property being an IList.  The TargetMultiplicity is disabled so I can not change it to ZeroOne, which I hope would result in making the property a single object.

How can I change the TargetMultiplicity or better yet, how could I generate the correct setting from the database?

Thanks,

Al

[alo]

There appears to be a recent post that is similar to my question.  The thread "Modelling 1:1 association?" refers to another thread "Dependent property and cascading delete in visual designer" which seems to indicate there is no support for one to one relationships.  Can someone confirm if this is still the case?

If there is no support for one to one relationships, are there any suggested workarounds?  Can you just use a single instance in the list"?

Al

[Zoran]

Hi Alo,

 Unfortunately, that is still the case, 1:1 associations can not be modeled at the moment due to some restrictions in the OpenAccess runtime. For the moment you can workaround this issue looking into the single object that would be part of the collection on the n side of the association. Since we are getting more and more requests for this feature, we are evaluating the development required for it and we will schedule it for one of the next releases. At the moment we are preparing a KB article with a list of possible workarounds for different scenarios. 

I will give you an update in this thread after we have this KB uploaded.

Regards,
Zoran
the Telerik team

[Chuck]

I would like to bump this up on your list as well.  Thanks.

[Ivailo]

Hi Chuck, Albert,

The KB article regarding One to One relationships has been released and sample projects are provided for the workarounds available. You can find it at:
http://www.telerik.com/support/kb/orm/general/how-to-map-a-one-to-one-relationship.aspx

I hope it proves useful for your scenarios.

Best wishes,
Ivailo
the Telerik team

[IT-Als]

Hi Ivailo,

Thanks for samples.. But I don't see why this is a restriction of the OA runtime.
In the OA Classic is perfectly legal to have a one to one association between classes..  Can you elaborate on this.

I would like a "true" one to one association to be designed with the designer and then generated by OA to be used by the developer...

Regards

Henrik

[Ivailo]

Hi Henrik,

You are right that with the “classic” wizards it is possible to create a one to one relationship between two tables. In most of the cases this relationship works – the linkage is maintained and selecting either of the table you are getting records from both tables.

However, there is a limitation in this approach. When you try to insert a new row in both tables, a foreign key exception is thrown, since the order of the insert is not maintained properly. This means that while the one to one relationship might look slightly better in the classic wizards as a matter of data retrieval, it has the same problems with the insert command. The workarounds for that limitation would be the same as described in the knowledge base article.

We will consider implementing a better linkage maintenance in the Visual Designer (similar to the one used in the wizards) for one of the future releases in order to have easier data retrieval in such cases.

Do not hesitate to contact us in case you have any questions.

Best wishes,
Ivailo
the Telerik team

[IT-Als]

Hi Ivailo,

Thanks for elaborating on this issue. Looking forward to see the implementation in the designer.

Typically you only want to navigate in one direction. For example, consider 3 entities Customer, Address and Country.

Lets say that a Customer has a reference (association/aggregation) to an Address and an Address has a reference (association - one way only). Classes might look like this:

class Customer
{
    private Address address;
    .....
}

class Address
{
    private string streetName;
    private Country country;
    ....
}

class Country
{
   private string isoCode;
   .....
}

While the address has a (strong) relationship to the customer...  the country has a loose (what I call reference) to the Country... You can consider the Country to be a kind of system (global) data and the Address to be private to the entity that references it.

In both cases it is not possible to navigate back to the "owner"... ie.. the Address does not have a reference back to the Customer... that way the Address can be used with many other entities... like a Supplier for instance...

Does it make sense...

Regard

Henrik

[Chuck]

I would like to briefly describe my use case so it may be considered during any product changes, which may be slightly more complex (this is just one example).

I utilize a [User] object (and table) that can login to my application.  I also utilize an [Employee] object (and table), which are considered a resource within the application (they can be assigned work, etc.).  In some cases there may be [Users] who are [Employees], but some [Users] are not [Employees].  (They can fill out requests and do other tasks, but do not work for the organization and so cannot receive assignments.)  There are some [Employees] who are [Users], but there are also [Employees] who are not [Users].  (They are considered resources, but cannot log in to the system; supervisors will print out assignments and hand them to them).  This makes for a dual sided 0-1 relationship, and I would like to navigate in both directions, after checking for a null value.  In my current implementation, both [Users] and [Employees] have a unique autonumber primary key, and I only keep a single foreign key, [UserId], in the [Employees] table.

This design was chosen because it was desired to track additional items (and enable additional functionality) when an employee is logged in vs. a non-employee user.

Anyway, the point of this is to make sure the maximum flexibility is built into the system as Telerik implements changes in their product.  I also noticed that below the article (by title at least) specifically addresses One-To-One, and not Zero-To-One.

Thank you.

[Ivailo]

Hi Chuck,

Thank you for noting this scenario, we are certainly going to take it into account.

As per the current release, the workaround you have is similar to the One2Many approach described in the article, except that you would have to modify a bit the code for the One2Many approach to turn it into Zero2Many. The changes will be in the properties of the manually added partial classes – you would have to make sure you allow for missing objects in both ends of the relation.
The inheritance approach unfortunately is not an option for your case.

For further clarity, we will probably enhance the Knowledge Base article with a Zero2One sample and keep you guys posted.

Let me know if you have any other issues or suggestions. 


Best wishes,

Ivailo
the Telerik team

[alo]

I was wondering if a better approach is being released anytime soon???

Seems like a lot of people are interested in a better way to map a one to one relationship.

[Ivailo]

Hi Albert,

The priority of implementing native support for 1:1 relationships is high and we are trying to push the development as fast as possible. Due to the complexity of the task it will probably not make it for Q1 2012, but we do plan to release it in Q2 2012.

Thanks in advance for your patience.

Greetings,
Ivailo
the Telerik team

[alo]

Thanks for the update.  Q1 2012 would be great if possible.

Is this issue in the Public Issue Tracking System?

Al

[Ivailo]

Hello Albert,

I have added the "Implement native handling for 1:1 relationship" item to our Public Issue Tracking System. 

We would like to invite all of you that consider that feature crucial to vote for it there.

Greetings,
Ivailo
the Telerik team