I've implemented a similar enum setup to the one explained here : http://www.telerik.com/help/openaccess-orm/developer-guide-domain-model-class-mapping-use-enums.html
However I keep getting a warning : "The type for member with name 'EnumProperty' of the 'EnumDomainClass' persistent class is not a valid mapping for its column. C:\path\ClassLibrary\EntitiesModel.rlinq 0 0"
Is this usual? Should I ignore it?
It seems to work fine. But warnings... you know.... nice to clear them up.
Thanks
12 Answers, 1 is accepted
Hello Phil,
The warning is being shown when OpenAccess Validation Framework indicates that a given CLR type is a valid mapping for a column.Could you please provide us with additional information regarding the column’s SQL type and the enumeration definition?
We are looking forward to hearing from you.
Kind regards,
Damyan Bogoev
the Telerik team
The enum is declared like this:
public enum SystemRole { SystemAdmin = 0, User = 1, Manager = 2 }
(I'm being specific with values in the enum, as I'll be adding other SystemRole values and blocking the ranges, e.g. "ClientUser = 100", etc)
In the DB, SQL Server 2K8, the column is declared as int
I've included the domain class xml :
<
orm:class
name
=
"SystemUserRole"
behavior
=
"readwrite"
uniqueId
=
"14276741-073d-491e-8e16-60efdf808615"
>
<
orm:table
name
=
"SystemUserRoles"
/>
<
orm:identity
>
<
orm:multiple-field
>
<
orm:single-field
field-name
=
"systemUserId"
/>
<
orm:single-field
field-name
=
"allowedSystemRole"
/>
</
orm:multiple-field
>
</
orm:identity
>
<
orm:concurrency
strategy
=
"changed"
/>
<
orm:field
name
=
"systemUserId"
property
=
"SystemUserId"
behavior
=
"readwrite"
uniqueId
=
"4d5f021c-ebc1-49ea-b7bb-c00f814a87ad"
type
=
"System.Int32"
>
<
orm:column
name
=
"SystemUserId"
sql-type
=
"int"
nullable
=
"false"
length
=
"0"
scale
=
"0"
primary-key
=
"true"
ado-type
=
"Int32"
/>
</
orm:field
>
<
orm:field
name
=
"allowedSystemRole"
property
=
"AllowedSystemRole"
behavior
=
"readwrite"
uniqueId
=
"cfa34ec8-808b-4fe8-8d9b-c8c67d2bdd44"
type
=
"SystemRole"
>
<
orm:column
name
=
"AllowedSystemRole"
sql-type
=
"int"
nullable
=
"false"
length
=
"0"
scale
=
"0"
primary-key
=
"true"
ado-type
=
"Int32"
/>
</
orm:field
>
<
orm:field
name
=
"systemUser"
property
=
"SystemUser"
behavior
=
"readwrite"
uniqueId
=
"959dfabb-d297-4822-8b77-cb8c29e29163"
type
=
"Doner451.OpenAccess.SystemUser"
>
<
orm:reference
uniqueId
=
"1a749e63-3b05-425e-a763-b8d71b39a0da"
>
<
orm:sharedfield
name
=
"systemUserId"
target-class
=
"Doner451.OpenAccess.SystemUser"
target-field
=
"id"
/>
<
orm:constraint
name
=
"FK_SystemUserRoles_SystemUsers"
destination-table
=
"SystemUsers"
/>
</
orm:reference
>
</
orm:field
>
</
orm:class
>
Thanks
Phil
Hi Phil,
We have reproduced the behavior on our side. It seems to be an issue in our Validation API.We will fix this issue for the next release of the product.
Please find your Telerik points attached.
I am sorry for the inconvenience caused.
Kind regards,
Damyan Bogoev
the Telerik team
I just started getting this error message AFTER updating to OpenAccess 2012 Q2 2.607.
At present, there is one error for every enumeration that I have set in my RLINQ (attached).
Any idea how this can be fixed?
Wendy.
Could you please send us your rlinq file, so we could investigate this behavior? Normally this error should not be shown. In the meantime you can just ignore these errors, they are generated by the validation framework of OpenAccess and should not prevent your project from building and working.
You will probably not be able to attach the file in the forum, so please feel free to send us another support ticket.
Regards,
Alexander
the Telerik team
I've been having problems mapping enums to nullable columns. On first try I change the property type on the entity from Int32 to my enum, then everything seem to work fine except the generated property is MyEnum instead of Nullable<MyEnum>. On second try I flip the Nullable on the property from true to false then back to true. When saving the following message is shown in the error window: "Invoke validation method 'RunValidationFramework' failed". The generated code still contains a non-nullable property but now there is an extra "namespace" generated:
using System.Nullable`1[[<real namespace of my enum>;
An obvious syntax error.
Using 2013.2.702.1
For the nullable enums, to be more precise in the code generation for properties with nullable enums, we have some known issues. The work around is to specify the type as "MyEnum?" and set the Nullable property to false. Then the code will be correctly generated.
Please be aware that with your version you might experience some runtime issues with nullable enums, I would suggest you to update your OpenAccess to the latest build we have released (2013.3.1101.1). You can download it from here. (It is available once you have downloaded the official Q3 release)
I hope this helps. Please do not hesitate to get back to us with any questions you have.
Kaloyan Nikolov
Telerik
For smooth experience with the nullable enums at runtime you need at least our latest official release (Q3 2013). I offered you the internal build because it contains a bug fix for the issue described here. If your model doesn't use vertical inheritance than you can freely use the Q3 release.
To get the property properly generated just set the type as "MyEnum?".
Kaloyan Nikolov
Telerik
New bug: when joining on an enum column like so:
from d
in
db.Documents
join a
in
db.AccessControl on ObjectTypes.Document equals a.ObjectType
select
new
{ d, a }
the following exception is thrown:
No AdoTypeConverter has been registered for the clrType. Parameter name: clrType. Actual value was ObjectTypes.
The enum-mapped property is AccessControl.ObjectType. The enum field might be a part of a composite join expression (e.g. new{...} equals new{...}), the result is the same. If I cast the enum properties/constants to the base type (e.g. int) the query is generated successfully.
I can confirm that for the time being this is the only workaround you can use. We have added tests simulating the problem in our test suite and the issue is logged in our bug tracking system. Unfortunately I am not able to give time frame for this fix. It will be included in one of the next releases.
Thank you for your understanding.
Regards,
Kaloyan Nikolov
Telerik