[
https://issues.apache.org/jira/browse/OLINGO-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13816400#comment-13816400
]
Georgi commented on OLINGO-42:
------------------------------
Hi Chandan,
Thanks for the clarification.
In both of your comments above you are refer to very specific cases when
there's missing information to build the model. For these cases, I'd recommend
to provide for alternatives to the current approach:
If it's going to be olingo-jpa-provider-specific JPA model, then maybe an
olingo annotation is more appropriate than a constraint on the API design for
new JPA models. And an external descriptor is probably the way to adopt
existing JPA models that cannot be changed to conform the olingo design
requirements.Or something smarter?
On the other hand, what I referred to are all cases when there's enough
information already in the model to build a consistent EDM. In such a model,
a referencedColumnName can be inferred from the referenced Entity's primary key
annotation because it is not a compound key;
the foreign key column name is explicitly specified by the JoinColumn
annotation.
As a user of the library I can hardly justify why the existing data is not
utilized and i have to provide redundant one, not that much because I'm lazy (I
am , I admit :-) ), but because it's a big impediment as mentioned in my
original post.
The current approach may be easier to implement and more generic, but the
price for that is that it is also too constraining and intrusive and this is
not always tolerable.
By the way, it's not a bad idea at all to document these strong requirements on
the JPA model design for the 1.0.0 version since it's already out. I learned
them the hard way.
> jpa processor requires a redundant field for many-to-one relationships
> ----------------------------------------------------------------------
>
> Key: OLINGO-42
> URL: https://issues.apache.org/jira/browse/OLINGO-42
> Project: Olingo
> Issue Type: Bug
> Components: odata2-jpa
> Affects Versions: 1.0.0
> Environment: windows7, tomcat 7.0.42, hsql, eclipse link 2.5.0
> Reporter: Georgi
> Assignee: Chandan V.A
>
> It looks like that the only way to get a consistent EDM associations model
> and the corresponding navigation properties, when there are many-to-one
> (bi-directional) managed relationships, is to add an additional and redundant
> property, annotated with @Column to the owning class. Same as in your
> reference jpa model.
> However, it's highly unlikely that one models a JPA model like this in
> reality and quite an impairment particularly for existing models.
> I'm not sure why is that needed, because the information encoded in the
> required field @Column annotation is redundant with the one @JoinColumn
> annotation and you already parse the JoinColumn anyways.
> So probably that's a low hanging fruit?
> I also realized that specifying the optional in the JPA @JoinColumn
> annotaiton property referencedColumnName is yet another mandatory requirement
> for the JPA edm producer to create a valid navigation properties set.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
