Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entity framework CreateDatabaseScript gives false results [DNET379] #384

Closed
firebird-automations opened this issue May 13, 2011 · 16 comments

Comments

@firebird-automations
Copy link

Submitted by: Leonard Wennekers (l.wennekers)

Attachments:
SSDLToFB.cs
Tracker379.zip

Votes: 1

The result of the CreateDatabaseScript function from the EntityFramework gives a false result. The TableNames is uses are just the names of the Entity and not the real tablenames configured by it's configurations. The bug commes inside SSDLToFB.cs where I did some trials.

The same function CreateDatabaseScript also create some errors with associations. The maximum length of associations is 32 charaters by with the CreateDatabaseScript function they can bw much longer because they are concatinated from the entity names. This also gives some problems when using the script created.

@firebird-automations
Copy link
Author

Commented by: Leonard Wennekers (l.wennekers)

The files has some comments with the text

//IOLAN MODIFICATION

After this test a fix is made for creating the right tablenames for the CreateDatabaseScript function/

However for the length of the associations there is nothing done.

@firebird-automations
Copy link
Author

Modified by: Leonard Wennekers (l.wennekers)

Attachment: SSDLToFB.cs [ 11952 ]

@firebird-automations
Copy link
Author

Modified by: @cincuranet

status: Open [ 1 ] => In Progress [ 3 ]

@firebird-automations
Copy link
Author

Commented by: @cincuranet

Thanks for reporting, although the patch is wrong. The code is generated form T4 template and the template itself must be independent (because it might be run outside provider).

@firebird-automations
Copy link
Author

Modified by: @cincuranet

priority: Major [ 3 ] => Minor [ 4 ]

@firebird-automations
Copy link
Author

Commented by: Jens Duczmal (jensd)

Dear Jiri,

it seems, that the TableAttribute is still ignored. CreateDatabaseScript does contain only the Classname as Tablename, not the string declared in [Table("DifferentName)"]-Attribute.

Any Ideas, when this might be fixed? It will be very useful, if we could use CodeFirst inkl. generation Script.

Edit: Version 2.7 (and probably 2.7.5 as well, becuase this ticket ist still open)

@firebird-automations
Copy link
Author

Commented by: @cincuranet

Probably after 2.8 is out.

@firebird-automations
Copy link
Author

Commented by: Jens Duczmal (jensd)

Hm....anyway, thanks for this reply.

Remapping of Colum-Names does work already very well. Just the Tablename does make problems.
I believe the foreign-key-problematic might be much more difficult to fix, but I could live with this for the time being.

I would be very grateful if you could try to get the Table-Attribute fixed within 2.8.
All our Tables have Prefixes, and - unfortunetely - the prefixes are Numeric, so I just have no possibility to refactor my classes,
because a class can't start with a number. Of course, that's our problem, but because reading data does work very well
and it's just a matter of the ScriptCreation it's a bit disappointing.

We are struggling just 10 meters in front of the finishing line.

@firebird-automations
Copy link
Author

Commented by: @cincuranet

I'm trying it right now, and I have my EDMX model with entity name different from table name and the call to CreateDatabaseScript (on ObjectContext) gives right result. Can you provide a test case?

@firebird-automations
Copy link
Author

Commented by: Jens Duczmal (jensd)

Thanks, I appreciate this good news :)

I can send you something tomorrow morning GMT.
But I tried with CodeFirst, i.e. without EDMX. And I used the Table-Annotation like

[Table("100_Customer")]
public class Customer {

public int ID \{get;set;\}
public string Name \{get;set;\}
\[Column\("City"\)\]
public string Town \{get;set;\}

}

The Column-Tag for renaming a Column does work fine. But the similar Table-Tag does not.
But in order to be really sure I will test this tomorrow morning and I will attach a C#⁠-File or send it by mail.

@firebird-automations
Copy link
Author

Commented by: Leonard Wennekers (l.wennekers)

Thanks Jens for creating the test. I searched for my test but I lost It.
And Jiri good luck with fixing this bug.

@firebird-automations
Copy link
Author

Commented by: Jens Duczmal (jensd)

Sample file for CodeFirst with Table-Annotation

@firebird-automations
Copy link
Author

Modified by: Jens Duczmal (jensd)

Attachment: Tracker379.zip [ 12181 ]

@firebird-automations
Copy link
Author

Commented by: Jens Duczmal (jensd)

Sorry, the file is as big because I mistakely zipped the EF-Nuget-Package.

Just create an empty Database, change the file and start it.
You will see that for the Town-Property a field named "City" would be created.
But the Table will have still the name "Customer" instead of "MyCustomer".

Probably not the best example, but I'm not able to get "DropCreateDatabaseInitializer" running with Firebird.
So you have to create one empty by yourself.

@firebird-automations
Copy link
Author

Modified by: @cincuranet

status: In Progress [ 3 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: vNext [ 10470 ]

@firebird-automations
Copy link
Author

Commented by: Jens Duczmal (jensd)

Thank you, Jiri.
Keep up the great work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants