This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Above is a fragment of my model
- The IdentityMethod is set to KeyTable - Article & ArticleGroup inherit from TreeItem via ClassTable Inheritance - The data is intended for hierarchical display, ArticleGroups will contain sub-groups & articles. The one-to-many association is nullable
I've created a migration and got this code as a result :
public override void Up() { this.AddKeyTable("KeyTable", ModelDataType.Int32); this.AddTable("roles", null, new Field("Id", ModelDataType.Int32, false), new Field[] { new Field("Name", ModelDataType.String, false).WithSize(45)}); this.AddTable("users", null, new Field("Id", ModelDataType.Int32, false), new Field[] { new Field("Name", ModelDataType.String, false).WithSize(45), new Field("Password", ModelDataType.String, false).WithSize(100)}); this.AddTable("articlegroup", null, new Field("Id", ModelDataType.Int32, false), new Field[] { new Field("Name", ModelDataType.String, true).WithSize(100)}); this.AddTable("articles", null, new Field("Id", ModelDataType.Int32, false), new Field[] { new Field("Title", ModelDataType.String, true).WithSize(100), new Field("Content", ModelDataType.Blob, true).WithSize(65535), new ForeignKeyField("UserId", ModelDataType.Int32, false, "users", null, "Id")}); this.AddTable("userroles", null, new Field("Id", ModelDataType.Int32, false), new Field[] { new ForeignKeyField("RoleId", ModelDataType.Int32, false, "roles", null, "Id"), new ForeignKeyField("UserId", ModelDataType.Int32, false, "users", null, "Id")}); this.AddTable("treeitems", null, new Field("Id", ModelDataType.Int32, false), new Field[] { new Field("Index", ModelDataType.Int32, true), new ForeignKeyField("ParentId", ModelDataType.Int32, false, "articlegroup", null, "Id")}); }
Please note the last table code "treeitems". It's foreign key field "ParentId" doesn't seem to allow nulls. Why is that? I've explicitely set the association to be nullable in the designer? If I've done something wrong - can I still achieve my target result some other way, without manually modifying the migration code ?
Cheers |
|
|
|
|
I've just noticed an interesting behavior in the designer. At some point, I've deleted the association and re-added it, set the nullable property to true, and created the migration. The migration code was as expected. The nullable property was set to true. A while later I've edited the "Content" property on the "Article" entity, created another migration to update my db. The migration code contained the nullable property set to false. I'd say that this could be a small bug - or at least an inconsistent behavior.
|
|
|
|
|
Thanks for drawing our attention to this. It doesn't sound like you're doing anything wrong, but I am a bit puzzled as to why you are seeing foreign key changes when editing the "Content" property. Did you delete a table or association while you were in there? Could you clarify exactly the steps you took, at which points you created migrations and when the foreign key started going wrong? As a side note, manually modifying the migration code isn't a problem. This isn't like entity code, where we update it as you make changes: it is generated once, and you are then free to edit it as you need to. This is by design because people need to add stuff like indexes, data migrations, etc., so don't worry about relying on edited code -- we won't overwrite it. Of course, this doesn't absolve us from getting it right in the first place! |
|
|
|
|
No tables were deleted.
A few days ago I ran into a problem with the forementioned field not being nullable, so I've set it in the migration code manually. Today I've deleted the association (was trying to see if LS would permit something else - but it didn't) and added it again. I've set all the properties to their original values (nullable = true) and created and executed the migration - noticed that generated code was correct. I've lated edited the "Content" property b/c it was a BLOB and I needed a TEXT - created a 2nd migration and executed it, got an exception while adding an entity to the db and noticed that the field was not nullable again. |
|
|
|
|
Okay, pardon me for spelling this out but I want to make sure I have understood exactly what is happening. 1. You created some tables with a nullable Parent association and created a migration. The FK was wrongly generated as non-nullable in the AddTable call. 2. You edited the migration to make the FK nullable in the AddTable call. 3. You deleted the Parent association and recreated it, ensuring that the association was still nullable. You did NOT create a migration while the association was deleted... is that right? 4. You created a migration. The FK was correctly generated as nullable. Was this a ChangeColumn or an AddTable? I am assuming the former since the table containing the FK already existed. 5. You edited a setting of the Content property, which is on the derived class that the association is *NOT* part of. 6. You created a migration. LightSpeed generated another ChangeColumn call for the ParentId (or another AddTable?), even though you had not touched the association, and the FK was wrongly generated as non-nullable. In addition, when you ran this migration, you got an exception. Sorry to be so pedantic about this -- just want to make sure I am understanding things correctly because I'm a bit puzzled as to where some of the deltas are coming from and what diffs LightSpeed thinks it needs to make from version to version! |
|
|
|
|
[quote user="ivan"] Okay, pardon me for spelling this out but I want to make sure I have understood exactly what is happening. 1. You created some tables with a nullable Parent association and created a migration. The FK was wrongly generated as non-nullable in the AddTable call. 2. You edited the migration to make the FK nullable in the AddTable call. 3. You deleted the Parent association and recreated it, ensuring that the association was still nullable. You did NOT create a migration while the association was deleted... is that right? Yes 4. You created a migration. The FK was correctly generated as nullable. Was this a ChangeColumn or an AddTable? I am assuming the former since the table containing the FK already existed. I didn't add a table, I was trying to see if LightSpeed would permit me having a circular association by replacing the former association with an equivalent association on the TreeItems table. I created and executed a migration, but I got an exception while in-code migrator was running. I reverted the changes by removing the new association and recreating the old one. 5. You edited a setting of the Content property, which is on the derived class that the association is *NOT* part of. Yes 6. You created a migration. LightSpeed generated another ChangeColumn call for the ParentId (or another AddTable?), even though you had not touched the association, and the FK was wrongly generated as non-nullable. In addition, when you ran this migration, you got an exception. Didn't add a table, I got an exeption while adding an entity with it's parent == null (via WCF Ria). This is when I noticed that the issue persists. Sorry to be so pedantic about this -- just want to make sure I am understanding things correctly because I'm a bit puzzled as to where some of the deltas are coming from and what diffs LightSpeed thinks it needs to make from version to version!
No problem at all, I'm glad to help. let me know if you need my solution files to recreate the issue. [/quote]
|
|
|
|
