openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Weidele <daniel.weid...@uni-konstanz.de>
Subject Re: OpenJPA
Date Mon, 16 Apr 2012 20:46:53 GMT
Good evening, Kevin,

thanks for you explanations - I will investigate Object-to-XML mapping a
bit to gain further insights.

When you say JPQL and Criteria API are specified by JPA - does it mean that
JPA API already "ships with" lexing, tokenizer, etc.- and by that hard to
modify?
I'd more expect this to be a task of implemenations and by that part of
OpenJPA. If so, we should model a generic syntax in first place. Then we
could modify the scanning process to further be able to map to MySQL. When
I browsed through the MySQL GIS functionalities it also seems to be "ok" to
handle.

By the way - I solved the lack of a "distance"-function in MySQL by a
stored procedure. So now let's see how to perform it nicely from Criteria
API [I'd rather not like to rewrite my Criteria API queries to native SQL -
instead I'd prefer to put the efforts in extending the Criteria API - so,
tomorrow I'll have a look at Object-to-XML]

Good night!
Daniel


PS: I'm not sure whether to go on with this conversation in public or
switch to private mail?

2012/4/16 Kevin Sutter <kwsutter@gmail.com>

> Hi Daniel,
> You're on the right "mental" track.  Of course, it's not quite as straight
> forward...  Performing the Object-Relational mapping for spatial is
> probably the easiest part of the exercise.  Pulling the data values from
> the database, and persisting the data values back to the database is fairly
> straight-forward.  You can probably accomplish most of that today with
> minimal updates to the MySQL data dictionary (for use with OpenJPA).
>
> The more tricky aspect would be attempting to update the JPQL and/or
> Criteria API for being able to query across this data.  Since both of these
> are defined by the JPA specification, extending either of these is going to
> take some effort.  Unless you can map the spatial types to already existing
> primitive types (ie. BigDecimal, long, string, etc)...
>
> JPQL gets tricky because you would have to change the parser to pull out
> the next syntax.  These new constructs would then drive the generation of
> the SQL (which would be limited to MySQL in this case).  Lots of work.
>
> Extending the Criteria API may be a little more straight forward.  You
> would have to define the new methods for extending the Criteria API, which
> would drive down to creating the SQL.  OpenJPA's Criteria API meets up with
> the JPQL processing so that we only generate the SQL via a single process.
> This also provides us with the ability to dump out an equivalent
> "JPQL"-like string for Criteria API generated queries.
>
> I would probably consider extending our current implementation rather than
> just updating the current implementation.  Makes it easier to differentiate
> your extensions from the mainline code.  You might want to take a look at
> what we did for supporting Object-to-XML mapping.  Although different from
> what you are attempting, it should give you an idea of how we extended our
> current support and took advantage of common processing without
> re-inventing the wheel.  I know that the WebSphere product has done similar
> extensions for their JPA solution (built on top of OpenJPA).
>
> Good luck with your investigation!
>
> Kevin
>
> On Mon, Apr 16, 2012 at 12:40 PM, Daniel Weidele <
> daniel.weidele@uni-konstanz.de> wrote:
>
> > Hello Kevin,
> >
> > thanks for the @Embeddable annotation. However, I reviewed MySQL status
> and
> > it seems their spatial extension does not yet support a "distance()"
> > function. It looks like I have to contribute there, before contributing
> > here - because especially the "distance" function would be something I
> need
> > :-(
> >
> > Nevertheless, as you already mentioned - to provide full-feature support
> I
> > would as well say that @Embeddable is not enough. Of course modeling the
> > Geo-structures itself has to be done wisely - but my feeling is that the
> > more tricky part is teaching JPQL / Criteria API the geometry functions.
> > Until now I would not know where to start, as I have not that much
> insight.
> > I'd assume to have to provide some knowledge within a MySQL dictionary to
> > OpenJPA and then translate the "user" input (either from Criteria API, or
> > JPQL) - such that we have a generic language which is then translated
> into
> > MySQL syntax.
> >
> > Is this a "mental model" that fits the actual implementation mechanism,
> > somehow? Or am I totally wrong with the assumption - if not - do you know
> > some of the entry points which will be of interest?
> >
> > Best,
> > Daniel
> >
> >
> > 2012/4/16 Kevin Sutter <kwsutter@gmail.com>
> >
> > > Hi Daniel,
> > > There is no direct support for the MySQL spatial extensions in OpenJPA.
> > > You could maybe model the support by wrappering the constructs in an
> > > embeddable, but that may not give you the full support you are looking
> > > for.  You could always help develop this support in OpenJPA and
> > contribute
> > > it back to the community...  :-)
> > >
> > > Thanks,
> > > Kevin
> > >
> > > On Mon, Apr 16, 2012 at 10:15 AM, Daniel Weidele <
> > > daniel.weidele@uni-konstanz.de> wrote:
> > >
> > > > Hi folks,
> > > >
> > > > I'm wondering whether there is any non-native support for MySQL
> spatial
> > > in
> > > > OpenJPA?
> > > > It would be sufficient to have a perimeter search in Criteria API,
> e.g.
> > > > based on lon/lan stored as decimals.
> > > >
> > > > Best regards & thx for any suggestions.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message