[EF / C#] Entity key wordt niet herkend

[PdeBie]

C#:

using System;
using System.ComponentModel.DataAnnotations;

namespace xxxx.BusinessLayer
{
    public class Provincies
    {
        [Key]
        public Char ProvincieCode { get; set; }
        public String ProvincieNaam { get; set; }
    }
}

De error:
EntityType 'Provincies' has no key defined. Define the key for this EntityType.
Provincies: EntityType: EntitySet 'Provincies' is based on type 'Provincies' that has no keys defined.

In de database staat ook keurig een primary key op de tabel op het veld.

Wie o wie heeft er een idee?

ps. let niet op de naamgeving van de klasse en properties. Heb het zelf niet mogen bedenken helaas.

[Sebazzz]

Wellicht wordt er geen char ondersteunt als PK. Heb je dat al eens geprobeerd te reproduceren in een kleine testcase?

[PdeBie]

Nope, nog niet geprobeerd. Vind ik de foutmelding ook niet helemaal bij passen. Dan hadden ze wel iets van een 'unsupported'-achtige melding bedacht denk ik.

Maar ik kan het eens proberen.

[P-Storm]

Volgens mij mocht een Key inderdaad alleen een type integer of long hebben, Hier heb ik nog wat gevonden erover: http://blogs.msdn.com/b/d...-services.aspx#Section_17

[ Voor 46% gewijzigd door P-Storm op 16-06-2014 15:41 ]

[PdeBie]

Net test projectje gemaakt. Krijg als ik van 'ProvinceCode' een char van maak weer dezelfde melding. Maak ik er een int van niet meer.

Het lijkt er dus op dat char inderdaad niet is toegestaan als key. Wel vage melding dan

C#:

using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace EF_CharAsKey
{
    public class City
    {
        public City()
        {
        }

        public int CityId { get; set; }
        
        [ForeignKey("Province")]
        public int ProvincieCode { get; set; }
        public virtual Province Province { get; set; }

    }

    public class Province
    {
        public Province()
        {
        }

        [Key]
        public int ProvinceCode { get; set; }
        public string Name { get; set; }

    }
}


// In Console Application Main()
using (var ctx = new Context())
            {
                Province p = new Province() {Name = "naam", ProvinceCode = 1};
                ctx.Provinces.Add(p);
                ctx.SaveChanges();

                City c = new City() { CityId = 1, ProvincieCode = 1 };
                ctx.Cities.Add(c);
                ctx.SaveChanges();
            }

Maar hiermee is mijn probleem dus nog niet verholpen, want ik zit dus aan een tabel vast met een char als primary key. Hoe kan ik hier nou toch mee werken? Fluent ofzo?

[ Voor 6% gewijzigd door PdeBie op 16-06-2014 16:09 ]

[[ti]]

Volgens mij kun je gewoon:

C#:

        [Required, Key, MaxLength(1)]
        public string ProvincieCode { get; set; }

Doen. Char is iig niet geldig in EF en wordt niet gemapped naar een database type (zie MSDN: SqlClient for Entity FrameworkTypes voor de mappings, een database char is gewoon een string met maxlength 1 in ef).

[ Voor 30% gewijzigd door [ti] op 16-06-2014 16:36 ]

[PdeBie]

Top! Dat was hem!

Meteen even die link in m'n bladwijzers opslaan.

[BasieP]

Weer een prachtig voorbeeld waarom frameworks (zelfs van mighty microsoft) niet perfect zijn.

In mijn ogen moet een ORM zo veel mogelijk functionaliteit
a: in je database laten (performance en consistentie)
b: wat ie abstraheert zo goed mogelijk doen.

Weet iemand waarom hij niet gewoon een char PK kan maken?

[EfBe]

BasieP schreef op dinsdag 17 juni 2014 @ 15:43:
Weer een prachtig voorbeeld waarom frameworks (zelfs van mighty microsoft) niet perfect zijn.

In mijn ogen moet een ORM zo veel mogelijk functionaliteit
a: in je database laten (performance en consistentie)
b: wat ie abstraheert zo goed mogelijk doen.

Weet iemand waarom hij niet gewoon een char PK kan maken?

omdat EF met een EDM model intern werkt en vast zit aan EDM types en EDM kent geen Char type.

[[ti]]

BasieP schreef op dinsdag 17 juni 2014 @ 15:43:
Weet iemand waarom hij niet gewoon een char PK kan maken?

Dat kan ie dus wel (zie mijn voorbeeld). EF mapped een database char(1) simpelweg naar een string, met een maximale lengte van 1. Ik vermoed dat ze dit doen omdat een database char(1) en een char(n) simpelweg geen andere datatypes zijn en daarom dus altijd naar een string in EF gemapped worden.

[Sebazzz]

EfBe schreef op woensdag 18 juni 2014 @ 10:03:
[...]

omdat EF met een EDM model intern werkt en vast zit aan EDM types en EDM kent geen Char type.

Dit en andere zaken gaan ze dus met EF v.Next proberen recht te zetten, ik denk dat ze behoorlijk ook naar NHibernate kijken.

[BasieP]

EfBe schreef op woensdag 18 juni 2014 @ 10:03:
[...]

omdat EF met een EDM model intern werkt en vast zit aan EDM types en EDM kent geen Char type.

Wat wil je zeggen? EDM is onderdeel van EF. Dus het is een EF probleem, en dat had natuurlijk netjes in het framework rechtgetrokken kunnen worden door een database char(1) te converteren naar een char en niet naar een string.

Sebazzz schreef op woensdag 18 juni 2014 @ 13:56:
[...]

Dit en andere zaken gaan ze dus met EF v.Next proberen recht te zetten, ik denk dat ze behoorlijk ook naar NHibernate kijken.

Ja kijk dat is goed nieuws
ik hoop dat dit ze een beetje gaat lukken. Datatypeconversie blijft ongeveer het lastigste aan OR mappers bouwen.

[EfBe]

BasieP schreef op woensdag 18 juni 2014 @ 16:35:
[...]

Wat wil je zeggen? EDM is onderdeel van EF. Dus het is een EF probleem, en dat had natuurlijk netjes in het framework rechtgetrokken kunnen worden door een database char(1) te converteren naar een char en niet naar een string.

Wat ik wil zeggen? Precies wat ik zei. EDM is niet onderdeel van EF, EF gebruikt EDM, net zoals OData ook EDM gebruikt. Doordat ze EDM gebruiken hebben ze last van de betrekkelijkheid ervan. Ze hadden char(1) naar een char kunnen converteren inderdaad, ware het niet dat veel ADO.NET providers een char(1) als string teruggeven, dus je zit dan met een ambigue conversie, ookal omdat niet iedereen het als een char wil gebruiken in .NET, plus dat de conversie niet char(1) -> char is maar string[1]->char.

[...]
Ja kijk dat is goed nieuws
ik hoop dat dit ze een beetje gaat lukken. Datatypeconversie blijft ongeveer het lastigste aan OR mappers bouwen.

Welnee. datatypeconversie is erg simpel. En het systeem zit al in .NET: de TypeConverter class. Die typeconversies zijn een paar regels code en zeker niet het lastigste om te bouwen in O/R mappers, geloof me maar