Just a kind reminder: as for JPA use, I think we should avoid using any implementation-specific JPA annotations/semantics.to make our framework portable across JPA providers.
Gerald On Thu, Apr 21, 2011 at 10:55 AM, Franklin, Matthew B. <[email protected]> wrote: > 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 >>>> >>> >> >> > >
