I have committed a first-run, OpenJPA based persistence strategy for the
model. As noted below, I left the model objects as JPAPOJOs.
Having used mostly Eclipselink as a JPA provider, I found a few gotchas
when working with OpenJPA, some of which could have negative downstream
impact and should be looked at by someone who has more knowledge of the
OpenJPA implementation.
The outstanding issues are as follows:
1) Unidirectional OneToMany relationships require the fetch type to be
explicitly set to eager
2) I haven't found the correct approach for converting database types
to specific non-primitive types in Java. Eclipselink provides the
@Convert annotation for this purpose. Currently, the only issue is
the widget title, which is an InternationalizedString. I have marked
it as @Transient for the time being
I also have some placeholder db scripts that I was using to create the
database until I figured out that in order to generate the database on the
fly through OpenJPA, you need to have the enhanced entities. My next task
is to create a new test data load strategy and integrate that into the
code, then remove the database code.
-Matt
On 4/19/11 10:52 AM, "Franklin, Matthew B." <[email protected]> wrote:
>There are other issues with this approach as well. Namely, that you would
>need to create deep copies of the model objects passed into save or other
>persistence methods. I am going to stick with the JPAPOJO for now and we
>can explore other approaches as they come up.
>
>-Matt
>
>On 4/19/11 9:44 AM, "Raminderjeet Singh" <[email protected]> wrote:
>
>>I saw the same thing being done by Jesse in his commit yesterday. I
>>personally feel that makes JPA layer more difficult and more error-prone
>>also. Any add/removal of element in Model will need change all the JPA
>>classes where model is used. I may not have understood your idea
>>completely. I would like to see the code before making further comments.
>>
>>Thanks
>>Raminder
>>On Apr 19, 2011, at 8:19 AM, Franklin, Matthew B. wrote:
>>
>>> I was thinking a bit about the model objects as interfaces vs POJO vs
>>> JPAPOJO and thought of a slightly different approach. What if we keep
>>>the
>>> model objects as POJOs and allow the persistence layer to create their
>>>own
>>> model objects that extend the Rave model and decorate them according to
>>> their own persistence strategy? Since we (I think) all plan on
>>>treating
>>> the Rave model objects as POJOs, regardless of their underlying nature,
>>> this approach may serve everyone's needs.
>>>
>>> Unless there are objections, I am going to replace Jesse's mock
>>> persistence layer with a JPA layer that hits an in-memory database and
>>> uses the strategy outlined above.
>>>
>>> -Matt
>>>
>>
>
>
