[
https://issues.apache.org/jira/browse/OLINGO-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806247#comment-13806247
]
Chandan V.A commented on OLINGO-43:
-----------------------------------
Hi Georgi,
I have added a new method to ODataJPAContext. Following are those two methods.
=======================================================================================
/**
* The method sets into the context whether the library should consider
default naming for
* <ul><li>EdmProperty</li>
* <li>EdmComplexProperty</li>
* <li>EdmNavigationProperty</li></ul>
*
* @param defaultNaming is a boolean value that indicates if set to
* <ul><li>true - default naming is considered in case no mapping is
provided.</li>
* <li>false - default naming is not considered in case no mapping is
provided. The
* name provided in JPA Entity Model is considered.</li>
* </ul>
*/
public void setDefaultNaming(boolean defaultNaming);
/**
* The method returns whether the library should consider default naming for
* <ul><li>EdmProperty</li>
* <li>EdmComplexProperty</li>
* <li>EdmNavigationProperty</li></ul>
*
* @return
* <ul><li>true - default naming is considered in case no mapping is
provided.</li>
* <li>false - default naming is not considered in case no mapping is
provided. The
* name provided in JPA Entity Model is considered.</li>
* </ul>
*/
public boolean getDefaultNaming();
=======================================================================================
In the Service Factory set default naming to false into the ODataJPAContext
(oDataJPAContenxt.setDefaultNaming(false)). Based on this context parameter
library shall not transform the Names for "EdmProperty", "EdmComplexProperty"
and "EdmNavigationProperty". Since the default behavior of the library was to
transform the names the method provides a mechanism to switch off the default
naming behavior by setting the value to false.
I hope this solves your use case and also gives a minimalist kick start from
JPA models.
Regards
Chandan
> Minimalistic kikstart from JPA models
> -------------------------------------
>
> Key: OLINGO-43
> URL: https://issues.apache.org/jira/browse/OLINGO-43
> Project: Olingo
> Issue Type: Improvement
> Components: odata2-jpa
> Affects Versions: 1.0.0
> Reporter: Georgi
> Assignee: Chandan V.A
>
> Currently, the JPA EDM producer mechanism creates the EDM schema based mainly
> on the java types and a naming convention that it introduces (e.g. sufix
> Details for navigation properties, capital first letter for properties,
> etc.). It is great that there's a mechanism to change particular names via a
> mapping.xml.
> But it would be a lot better if you addressed the problem that if I already
> have a JPA model, it's quite likely that I already have considered proper
> naming in the my model and the least I'd expect is that it changes. Then it
> would be an additional, unwanted effort for me to create and maintain a
> mapping file that retains the semantics that i had in mind, to fix this.
> My expectation would be to see rather in the EDM schema the property names
> I've chosen in my JPA model, including those that represent CMRs. I also
> don't quite understand the effort to capitalize each first letter of a
> property name since it's not a mandatory convention and more importantly
> brings in differences to what I've already had in mind when creating my JPA
> model.
> My proposal is to respect the JPA model property names and metadata when
> creating the EDM model. The role of the mapping file then would be minimized
> to really specific cases.
> I'd also propose to extend the customization options to be able to influence
> the naming mechanism by configuration. For example if i wanted to omit the
> Details suffix to provide an empty string for that or if i wanted another
> suffix to provide the corresponding string to use.
> Together with the fix of the issues reported in
> https://issues.apache.org/jira/browse/OLINGO-42 that would mean one click
> expose of a JPA model as odata and I think will significantly improve the
> state as of now.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
