Errors in mapping Persistent types as Domain method result

Hi,

Model naming settings are not used in mapping persistent types to domain method results.
For example let's create stored procedure


Although this simple stored procedure would be retreived and the result shape would be created, let's go the hard way and create domain class proc_Temp_Result with property user_id (Guid) (see attached proc_Temp_Result.png) and then set proc_Temp_Result as a Persistent Type result (see attached proc_temp_mapping.png).

When you try to run following code

the following error appears


However, if you change property name to userId (see proc_Temp_Result_2.png), the error will disappear.
One would think that enabling "Default mapping" would clear this error without changing property names, but no, it still appears.
Model naming settings for properties are all "Unchanged"..

Telerik OpenAccess ORM 2012.2.816.1

Jacek

Hello Jacek,

 Upon mapping the result of your stored procedure to the specified persistent type we are getting the underlying table for the persistent type and comparing the columns of it to the columns being returned by the stored procedure itself.
Since you have not provided any mapping for your proc_temp_result class a default mapped table will be produced during runtime and our default rules for naming generation will be applied. In the first case your user_id property will result in the column user__id which is indeed nowehere to be found in the result type of your stored procedure. 
When you rename your property the default naming generation makes the auto generated column name match the returned column name and thus everything works as expected.
A possible solution for this would be to provide explicit mapping where you can define the column name to be exactly the same as the one being returned from your stored procedure.

All the best,
Petar
the Telerik team

Hi Petar,

Please note that proc_temp_result is strictly a "virtual" class, with no underlying table, so the explicit mapping is impossible.
Currently it is the only way to manually map results from stored procedure when result shape cannot be retrieved by the wizard
(currently there is no way to manually design or edit Domain Method Result Shapes so I have to use "virtual" Persistent types).

The problem with default mapping (which is the only option possible in this scenario) is that it ignores model naming settings.

Thanks,
Jacek

Hello Jacek,

 The idea to not be able to design the Domain Method Return Shapes is actually intentional. The sole purpose of those classes is to act as a POCO for your application where your stored procedures would return a normal CLR object rather than an object array as it was before. Even though you are not able to manually edit a Return Shape you are always able to go to the stored procedure editor and edit an already mapped stored procedure. During edit you are able to update the return shape to the latest version of the result type of the stored procedure. Using this you can make sure that your return shape always matches your stored procedure result shape and thus you will not need to do the sync manually.

By adding the return shapes to the domain model you are abusing the idea behind the return shapes. Generally what you are looking after is a transient class that is represented in the dsl diagram, however this is not supported and everything that is on our designer is considered to be persistent and therefore associated with either a table or a view. The transient non persistent classes reside in the domain method return shape collection and should stay there.

Greetings,
Petar
the Telerik team

Hi Petar,

Ok, could you explain how can I "update the return shape" when the stored procedure editor only retrieves error "Unable to retrieve result shape" (please find attached) - which was my main problem and I was looking for possible workarounds with persistent types.

I was following this and this thread - maybe I misunderstood something.

Kind Regards,
Jacek

Hello Jacek,

 I see. Well unfortunately what you are trying to achieve is not currently supported. As I said earlier in order to respect your database mapping we need to have it defined in the model and since we dont have it we are applying our own understanding of database naming generation and thus some mismatch is happening for you.
We will try to provide a fix for that although I am not sure if a fix is really applicable as we cannot really account for all the possible cases.
Would it be possible for you to just go with the naming that has worked for you and that does not produce an error?
Please find your Telerik points updated.

Greetings,
Petar
the Telerik team

Hi Petar,

So far I'm doing fine with just renaming the properties of "virtual" domain class.

The error appears with stored procedures that use #temp tables. However when you replace #temp table with function that returns table, OA designer can return and create result shapes as intended.

Kind Regards,
Jacek

Hello Jacek,

 We are aware of the issue with the tamp tables and it we will definitely be fixing it for one of our next official builds.
I am happy that you have managed to work around the problem and I am truly sorry for any inconvenience it might have caused you.

All the best,
Petar
the Telerik team