Persistence

["Franklin, Matthew B." <mf...@mitre.org>]

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

Re: Persistence

["Franklin, Matthew B." <mf...@mitre.org>]

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" <ra...@gmail.com> 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
>> 
>

Re: Persistence

[Raminderjeet Singh <ra...@gmail.com>]

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
>