OpenAccess ORM errors reported but VS2010 builds

[Carl]

I've created an entity diagram using reverse mapping from SQL Server 2008 database. The project in VS2010 builds without any errors reported by the compiler.

However, when viewing the entity diagram in the Visual Designer, there are numerous errors reported in the error list window. Most of them are either of the following two kinds of errors:

The column Version is specified as an autoincrement but it is not a primary key column. 

The meta model contains one or more parameters with negative lenght. 

Can these errors be safely ignored? How to reconfigure OA ORM so that they are not generated?

Thanks.

[Damyan Bogoev]

Hi Carl,

These messages are reported by the OpenAccess' validation framework. They report errors and warnings in the domain model but do not prevent the solution from compilation. They can be ignored but later this can lead to a runtime issues. 

I recommend you to read this blog post and this help article which provide additional information regarding the validation framework of the product.

Hope that helps.

Kind regards,
Damyan Bogoev
the Telerik team

[Carl]

Thanks for the answer and the links.

I am continuing to educate myself about OpenAccess ORM by reading the help, blog posts, and watching the videos, etc.

But, in general, I continue to question the reliability of round-tripping. I have already experienced enough situations where, at least in my hands on my machine (Win 7 64-bit, VS2010 Ultimate), I am unable to get round-tripping to work as I would expect it to work.

For example, I start by creating a new domain model from database with a few tables. Then I have an OA ORM domain model that compiles fine. Then I go back and add a few more tables from the database to the domain model. But it turns out that this a multiple step process where first you have to use the Update From Database Wizard then second you have to go to the Schema Explorer and map to persistent type. It does not seem terribly productive to have to make it a two-step process instead of a one-step process, but OK, at least if I could get it to work. But no, I cannot get it to work, and it does not seem to be smart enough to recognize the associations and foreign key constraints etc on the new tables then I have just added... so then I would have to go and redo that manually.

On the other hand, if I include ALL the tables I might need in the very first creation of the domain model at the very beginning before any round-tripping, then OA ORM does seem to be smart enough to recognize all the associations between the tables and all the foreign key constraints properly. In other words, for me in my hands, this proves that round-tripping does not work as I would expect it to work in a way that would be useful and convenient, so it's difficult for me to rely on round-tripping.

Now maybe I am missing something and I have not yet learned how to use OA ORM correctly. But until I am better educated or otherise until the tool is made more reliable with better round-trip re-synchronization between database schema model and conceptual domain model, I will rely on only using domain models that are created on first attempt, and otherwise avoid round-tripping.

By the way, is it possible to have one chosen name for software artifacts for the "database schema model" and a different chosen name for the "conceptual domain model"? And in the developer user interface for OA ORM, what about less confusing names for the windows than "Model Schema Explorer" and "OpenAccess Model Explorer"? It would be so much less confusing if these windows and their associated models had more clearly different names even if it was just something like "OpenAccess Database Schema Explorer" versus "OpenAccess Conceptual Model Explorer" which makes clear the distinction between the window for the Database Schema and the window for the Conceptual Model.

[Damyan Bogoev]

Hello Carl,

1. This is actually on our to-do list. We plan to provide a UI that would be part of the Update From Database wizard, where you will chose which parts should be immediately applied to your conceptual model. In case you select "All" than it will actually be a one step process.

2. The associations between the tables should be properly resolved. Can you give us a bit more information about the unresolved associations? The only case where we might not resolve an association correctly would be if a foreign key column, points to a non-primary key column from the target table. That kind of foreign key constraints are not supported at the moment. 
3. Yes, you could provide different names for your persistent classes. 

4. We do not consider changing the names of our explorers or dialogs for now but that will be a point of discussion in our team after your suggestions, so it is a possibility for the future. 

Regards,
Damyan Bogoev
the Telerik team

[Carl]

Re #1: Glad to hear that it is on your To-Do list.

Re #2: Yes, my database schema does have foreign keys that point to non-primary key columns. It is a reasonably sophisticated, but coherent, design that is described in a paper you can download from here:

http://www.mdpi.com/1999-5903/2/2/156

where you can find diagrams of the database schema and explanations in the text. If you'd like me to beta-test the next build of OpenAccess ORM that is supposed to be able to handle these kinds of associations, I'll be happy to do that for you.

Re #4: I hope that you will consider making the names more clear to prevent confusion, and I will continue to suggest "Database Schema Explorer" versus "Conceptual Model Explorer" or at least something that clearly contrasts the "Database Schema" from the "Conceptual Model". Another alternative would be "Database Schema Explorer" versus "Conceptual Domain Explorer" so that there is no use of the word "model" at all and then there's no confusion about which model the term "model" refers to.

[Damyan Bogoev]

Hello Carl,

First of all I would like to thank you for the valuable input.

Currently it is not part of the plans for the near future to add support for foreign key constraints that do not point to primary columns. The bottom of the issue is that one object is being identified only by its identity members. When there is a reference to a persistent object, the lazy loading mechanism retrieves the required object by its id - which is preserved in the foreign key column. If the value in the foreign key column was not the value of the primary key of the referenced object, the OpenAccess runtime is not able to understand which object should it load from the database as there is no information for its Id column.
However I do agree that this is a perfectly valid scenario and yes, we need to have support for it. We will do our best to have this feature as soon as possible on our roadmap. 

Hopefully my answer has shed some light on this issue.

You could follow our roadmap where the planned features for the next release of the product are presented.

Kind regards,
Damyan Bogoev
the Telerik team