I have committed a new strategy for pre-loading the in-memory database with data defined in SQL scripts. This strategy will work for both test and web application runtimes and can be modified/turned off from the application context.
The end result is that OpenJPA is creating the tables based on the annotations and the initial data scripts are being executed after the tables are created. -Matt On 4/21/11 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 >>>> >>> >> >> > >
