Adding JPA support

[Ricardo Gladwell]

Hi guys

I'm in the process of extending javageomodel to support JPA and submit
it as a patch:

https://github.com/rgladwell/javageomodel/tree/jpa-support

I'm having one problem with the LocationCapable interface. Currently it
defines the following property getter method interface to retrieve the
list of geocells:

List<String> getGeocells();

However, JPA 1 doesn't support collections of primitives[1]. I'm trying
to figure out a way around this problem. One way around would be to
re-define this method interface as:

List<Geocell> getGeocells();

Where Geocell is a new bean with just a String "value" field member. Of
course, this may not be backward compatible. Thoughts?

[1] http://db.apache.org/jdo/jdo_v_jpa.html

--
Ricardo Gladwell <ricardo....@gmail.com>
http://www.google.com/profiles/ricardo.gladwell
Twitter: @rgladwell - MSN: axo...@gmail.com

[Alexandre Gellibert]

I've just checked what you did, looks like a great job! Thanks for the
testing classes also.

Not sure about your solution with the Geocell class instead of
primitive String. It would be a regression for JDO interface. Maybe
you can manage this JPA specificity in JPAGeocellQueryEngine class
(like create object Geocell from the string at this stage).

I'm adding you as a commiter of the project.

Thanks,
Alex

On Dec 6, 8:14 pm, Ricardo Gladwell <ricardo.gladw...@gmail.com>
wrote:

> Hi guys
>
> I'm in the process of extending javageomodel to support JPA and submit
> it as a patch:
>
> https://github.com/rgladwell/javageomodel/tree/jpa-support
>
> I'm having one problem with the LocationCapable interface. Currently it
> defines the following property getter method interface to retrieve the
> list of geocells:
>
> List<String> getGeocells();
>
> However, JPA 1 doesn't support collections of primitives[1]. I'm trying
> to figure out a way around this problem. One way around would be to
> re-define this method interface as:
>
> List<Geocell> getGeocells();
>
> Where Geocell is a new bean with just a String "value" field member. Of
> course, this may not be backward compatible. Thoughts?
>
> [1]http://db.apache.org/jdo/jdo_v_jpa.html
>
> --

> Ricardo Gladwell <ricardo.gladw...@gmail.com>http://www.google.com/profiles/ricardo.gladwell

[Ricardo Gladwell]

Hi Alexandre

On 11 December 2010 22:39, Alexandre Gellibert

<alexandre...@gmail.com> wrote:
> I've just checked what you did, looks like a great job! Thanks for the
> testing classes also.

Thanks, it's not finished yet but hoping to have something working soon.

> Not sure about your solution with the Geocell class instead of
> primitive String. It would be a regression for JDO interface. Maybe
> you can manage this JPA specificity in JPAGeocellQueryEngine class
> (like create object Geocell from the string at this stage).

I think I could use @PostUpdate and @PostLoad to convert the list of
strings from the LocationCapable interface into a comma separated
VARCHAR string of geo-codes for JPA storage, and use the LIKE operator
to query that. Can you see any issues with this approach? Could
running "LIKE <geocode>" on such a string ever match more than one
geo-code by accident?

Just for consideration: would there ever arise a future change to the
javageomodel API which would require additional fields for Geocodes
such that a full entity-mapping would be required?

> I'm adding you as a commiter of the project.

Thanks! Will check my stuff in as soon as it is complete.

--
Ricardo Gladwell <ricardo....@gmail.com>