This question is locked. New answers and comments are not allowed.
You now provide reverse mapping of views - great.
The resulting classes require a primary key - and it is understandable that this can't be derived from the view in the database.
However, having created the class and indicated the primary key, everytime I perform a merge, i am told that the schema differ due to the fields that have been marked.
No big issue you say, but with more thna a very small number of views that are mapped, I have to visually inspect the sumary to find any changes which are important inbetween all the "noise" of irrelevant changes.
Any chance that you could sort this out - not sure the best solution since it will depend on how people are usign the product.
The resulting classes require a primary key - and it is understandable that this can't be derived from the view in the database.
However, having created the class and indicated the primary key, everytime I perform a merge, i am told that the schema differ due to the fields that have been marked.
No big issue you say, but with more thna a very small number of views that are mapped, I have to visually inspect the sumary to find any changes which are important inbetween all the "noise" of irrelevant changes.
Any chance that you could sort this out - not sure the best solution since it will depend on how people are usign the product.
3 Answers, 1 is accepted
0
Accepted
Hi Andrew,
Actually this is a bug with the merge process. When you mark a column as a field as primary key for a view this should not be marked as different, therefore it should not be shown in the merge wizard. We will fix that for the next release. Thank you for bringing this to our attention. Your Telerik points were updated.
All the best,
Petar
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Actually this is a bug with the merge process. When you mark a column as a field as primary key for a view this should not be marked as different, therefore it should not be shown in the merge wizard. We will fix that for the next release. Thank you for bringing this to our attention. Your Telerik points were updated.
All the best,
Petar
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
0
Shawn Krivjansky
Top achievements
Rank 1
Rank 1
answered on 13 Jul 2010, 07:53 PM
I am currently using the latest released version of the OA ORM (domain model) 2010 Q1 and this is still a very annoying problem.
Because a VIEW cannot have a primary key marked at the DB level, and after you set the Primary Key for a field in your ORM domain model (VIEW).... everytime you try to update from database, you will ALWAYS get a difference on the VIEW because the DB says the field you marked in the model as Primary Key is NOT a Primary Key at the DB level (which is impossible).
Picture attached.
Is this going to be fixed anytime soon?
If not, I'm not sure how anyone could use VIEWS where you have more than a couple of them because the maintenance and manual effort into checking them all the time would far outweigh any benefits.
Because a VIEW cannot have a primary key marked at the DB level, and after you set the Primary Key for a field in your ORM domain model (VIEW).... everytime you try to update from database, you will ALWAYS get a difference on the VIEW because the DB says the field you marked in the model as Primary Key is NOT a Primary Key at the DB level (which is impossible).
Picture attached.
Is this going to be fixed anytime soon?
If not, I'm not sure how anyone could use VIEWS where you have more than a couple of them because the maintenance and manual effort into checking them all the time would far outweigh any benefits.
0
Hi Shawn Krivjansky,
I am happy to let you know that this issue is now fixed. The fix will be available in the Q2 2010 release (due this week).
Do not hesitate to write again if you have more questions.
Best wishes,
Jordan
the Telerik team
I am happy to let you know that this issue is now fixed. The fix will be available in the Q2 2010 release (due this week).
Do not hesitate to write again if you have more questions.
Best wishes,
Jordan
the Telerik team
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Explore the
Telerik Public Issue Tracking
system and vote to affect the priority of the items