This is a migrated thread and some comments may be shown as answers.

Changing field to nullable doesn't update the schema

6 Answers 194 Views
Design Time (Visual Designer & Tools)
This is a migrated thread and some comments may be shown as answers.
This question is locked. New answers and comments are not allowed.
Bernd
Top achievements
Rank 2
Bernd asked on 04 Sep 2013, 08:07 PM
Hello all.
I want to change an association from 1:1 to 0:1. So I changed the foreign key property from nullable = false to nullable=true. Updating the database from model says: nothing to do.
As the association setting still were nullable=false I changed them too. Same result.
Shouldn't the database field be changed to nullable?
Kind regards
Bernd

6 Answers, 1 is accepted

Sort by
0
Doroteya
Telerik team
answered on 09 Sep 2013, 11:22 AM
Hello Bernd,

Generally, the behaviour you are describing is the designed one of Telerik OpenAccess ORM. In Database-First and Round-Trip scenarios, where the table already exists in the database, the Update Database from Model wizard does not generate scripts that will set the nullability of a primary key column to False.

In fact, I am unable to completely understand the scenario you are trying to implement and it would be really helpful if you could share a little bit more details about the tables, their columns and the relevant settings in the database.

Additionally, you can check the How to: Create One-To-One Associations article in our documentation.

I am looking forward to your feedback.


Regards,
Doroteya
Telerik
OpenAccess ORM Q2 2013 brings you a more powerful code generation and a unique Bulk Operations support with LINQ syntax. Check out the list of new functionality and improvements shipped with this release.
0
Bernd
Top achievements
Rank 2
answered on 09 Sep 2013, 02:39 PM
Hello Doroteya.

I understand that behaviour for primary keys. I don't understand it for foreign key fields.

First it wasn't intended to have transactions without relation to an operation. Well. That changed and I changed the association.

The model snippet:

I set Operation ID to nullable, Unmap and default map the table again.

The association:



I changed the field manually. But I would expect OpenAccess to recognize the change and generate a proper script. Am I wrong or is there something to be aware of?

Hope this helps to understand the scenario.

Thanks for your help.
Bernd
0
Doroteya
Telerik team
answered on 13 Sep 2013, 06:49 AM
Hello Bernd,

Thank you for your cooperation and for the details.

I tried to reproduce the behavior you describe according to a possible workflow I derived from the provided information and a script that would change the nullability of the foreign key was generated on our side. Please kindly find attached to this message a sample code library with a domain model in it that contains two default mapped classes and the scripts generated by the Update Database from Model wizard on each change of the model. The steps I performed are as follows:
1. Create a Telerik OpenAccess Class Library and an empty domain model.
2. Create two classes according (as described here) and populate them with properties (as described here).
3. Create a One-To-One association between the classes (as described here).
4. Default map both of the classes.
5. Run the Update Database from Model wizard and migrate the model to the database (TestDBConnection(2013-09-13 09-16-00).rlinq.sql).
6. Introduce a new property in DomainClass2 that will be the new primary key for it.
7. Set the IsPrimaryKey property of DomainClass2.Id to False.
8. Unmap and default map DomainClass2.
9. Run the Update Database from Model wizard and update DomainClass2 with the new primary key column (TestDBConnection(2013-09-13 09-18-33).rlinq.sql)
10. Change the Nullable property of DomainClass2.Id to False
11. Unmap and default map DomainClass2
12. Run the Update Database from Model wizard and update DomainClass2 (TestDBConnection(2013-09-13 09-19-20).rlinq.sql)

Could you check both the settings of the domain model and the executed workflow and let us know if they are similar to those on your side and if you perform additional steps?

I am looking forward to your feedback.


Regards,
Doroteya
Telerik
OpenAccess ORM Q2 2013 brings you a more powerful code generation and a unique Bulk Operations support with LINQ syntax. Check out the list of new functionality and improvements shipped with this release.
0
Bernd
Top achievements
Rank 2
answered on 13 Sep 2013, 02:51 PM
Dear Doroteya.

Thank you for your reply.

I am not available the next two weeks. So it will take some time to check it on my side. I'll answer as soon as I have a result.

Sorry for the delay.

Bernd
0
Bernd
Top achievements
Rank 2
answered on 26 Nov 2013, 12:53 PM
Hello Doroteya.

Sorry for the long time of no reaction.

Two differences in the model
1. I have disabled logging.
2. I have "Allow table removal" enabled.

Next I didn't change the primary key. OperationID is the foreign key in another entity. Which is not shown completely on the screenshot.

Taking your project I
1. changed PrimaryKey" to nullable false.
2. disabled logging in the model settings.
3. changed the connection string to my local one.
4. created the database with "Update database from model".
5. changes PrimaryKey to nullable true.
6. again used "Update database from model" and no script is generated. I only can select "Cancel".

Hope this helps
Bernd
0
Doroteya
Telerik team
answered on 29 Nov 2013, 11:40 AM
Hi Brend,

Thank you for your feedback.

Generally, the outcome you describe with the workflow from your last message is the expected one - OpenAccess ORM will not generate a script that sets the nullability of a primary key database column to False. Moreover, a validation error regarding this setup will appear in Error List (more about our Validation Framework is available here). Additionally, in the context of generating a script that changes the nullability in the database, the states of the logging and the Allow table removal properties are not relevant.

In fact, the domain models generated with OpenAccess ORM are logically split in two parts: a conceptual model and a storage model. The conceptual model is the abstract specification for the persistent classes, the complex types and the associations - the schema you see in Visual Designer. The storage model defines the underlying tables, columns, stored procedures, foreign keys and indexes - you can see it when you open the model in Visual Designer and select Model Schema Explorer.

In other words, in order to change the nullability you need to set Nullable to True in Visual Designer for the property and to check the Allow nulls check-boxt in Table EditorHere is an article that demonstrates the process. After applying the necessary modifications you can save the domain model and run the Update Database From Model wizard.

I hope you find this feasible. If you need further assistence, do not hesitate to get back to us.



Regards,
Doroteya
Telerik
OpenAccess ORM Q3 2013 simplifies your model operations even further providing you with greater flexibility. Check out the list of new features shipped with our latest release!
Tags
Design Time (Visual Designer & Tools)
Asked by
Bernd
Top achievements
Rank 2
Answers by
Doroteya
Telerik team
Bernd
Top achievements
Rank 2
Share this question
or