Entity Framework Data Annotations?

Elements Silver
1

I added Entity Framework with NuGet. It was looking promising. I was able to add a Table annotation to a Swift class, named TableAttribute instead of Table, but it looked like the right equivalent. But trying to add a property annotation brings up a parsing error. It happens as soon as I type the opening bracket, although the screen capture shows my attempt to finish it.

I’m trying to do the Swift equivalent of this C#

[Table(“ParentTable”)]
public class Parent
{
[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public int ParentID { get; set; }

and so forth. which I imagine would be something like this

[TableAttribute(“ParentTable”)]
public class Parent {
[KeyAttribute]
[DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
public var MyParentID: Int
}

Of course another issue is if EF will be able to handle Swift classes, which I’m willing to wrestle with, unless EF Data Annotations aren’t supported in Silver anyway.

2

As a parenthetical minor but kind of annoying issue, when I’m in a Swift project and use “Project / Add new class” it brings up the RemObjects C# Add New Item window with “Class” pre-selected instead of RemObjects Swift. If I use “Project / Add New Item” it works as expected.

3

Swift’s syntax for attribute is @, eg.

@Table("ParentTable")
public class ....
1 Like
4

Classes are classes. This is all .NET, no matter what language it’s written in. EF won’t even know what language you used.

1 Like
5

I’m having a problem in getting my DbContext class recognized. This may be my deficiency in Swift and not a Silver problem.

My DbContext class is this

public class SilverEFEntities: DbContext {
init (){
super.init(“name=SilverEFConn”)
}
}

Whose init() I would think is a default initialization/constructor, but I’m getting this.

“SilverEFConn” is a connectionString defined in App.config. When I comment out the init() a SiverEF.SilverEFEntities database is created and I can add a blank migration, update the database, and the MigrationHistory table is created. In trying to add a migration of two tables it fails saying the child doesn’t have the ParentID property, when it apparently does.

I commented out the ForeignKey attribute and it failed again saying that I don’t have keys, though they have the KeyAttribute.

Since the whole zipped project is 10 megs I include only the relevant source files in case you care to see if I’m doing something blatantly wrong in the code. I can upload the whole thing if you like. I’ve implemented Entity Framework in C# at work. I’m trying to mirror what has worked in C# with Silver Swift.
SilverEF.zip (1.9 KB)

6

Hmm. i gotta admit i dont know much about how EF itself works. These now all sound like errors from inside EF — like it doesn’t like your classes or the attributes on them — not for reasons caused by Silver, but because it’s just unhappy about what the classes look like.

The first screenshot, the message sound like you need a public constructor (public init()) on the class, rather than an internal one. The rest i’m not sure about, i’m guessing maybe ParentID needs t be mad public, or get an attribute? (again, i don’t know much about EF itself).

hth,
marc

7

Thanks for your suggestions. Ah! Yes, public may be missing where needed. I’ll try that. And I intend to see if there is something different I must do in Swift for multiple annotations/attributes. Thanks again. If I get success I’ll send you the project so it could be used as an example if needed. I think ET is the most popular NuGet package, so it would be great to see Swift handle it.

8

Just listing them all should work. example form one of my own projects:

@RemObjects.SDK.Server.ClassFactories.StandardClassFactory
@RemObjects.SDK.Server.Service(Name = "MyService", InvokerClass = MyService_Invoker.Type, ActivatorClass = MyService_Activator.Type)
public class MyService : RemObjects.SDK.Server.Service, ILastFMService { 
    ... }

definitely!

9

Making init() public removed the “not constructible” error (silly oversight on my part) and I can now target the database by the name I want. Still getting key errors, but now I’m suspecting it’s not the attributes, which seem correct, but perhaps something on how the properties need to be coded in Swift. I verified all of them are public. I’ll wrestle with it over the weekend. Thanks again for your suggestions!

10

I suggest having a look at the final .dll/.exe with Reflector or ILSpy — if anything looks off (say because of name unexpected name mangling), that would show it.

11

I followed your suggestion and viewed the binaries in Reflector. I don’t see name mangling (presuming I’m looking where I should. I haven’t had occasion to use this type of tool for .Net, only for C++) The attributes look correct. The difference that jumps out at me is that the key properties are pointers in the non-working Swift version and are straight value types in the working C# version.The keys are declared/defined as int vars in Swift. I don’t know if there’s a way to prevent them being made pointers, especially since they are supposed to be value types in Swift. The Name properties are kept as strings, not pointers, so I find it odd. Here’s the relevant code

@Table(“ParentTable”)
public class Parent {

@KeyAttribute
@DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)
public var ParentID: Int = 0

@Table(“ChildTable”)
public class Child {

public var ParentID: Int = 0

@ForeignKeyAttribute(“ParentID”)
public var Parent: Parent?

And here are the Reflector screen shots

Working C# Child

Non-working Swift Child

Non-working Swift Parent

12

Hmm. It’s only the integers that aren’t working I assume? Try using Int32 instead of (platform-sized) Int (which does map to IntPtr so it matches the platform size, and maybe EF doesn’t like IntPtrs).

13

Ah! That was it! The add-migration succeeded, as did the update-database -targetmigration:“BaseTables”. I like how the EF-generated C# migration files can be compiled with the Swift files in the same project. I now feel fairly confident that EF will handle Swift Silver fine, and if there’s an issue, it’ll most likely relate to some kind of typing issue. So I donated. Thanks again!

1 Like