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 < [email protected]> 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 <[email protected]> > > > 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 < > > [email protected]> 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. > > > > > >
