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 <kwsut...@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.weid...@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 <kwsut...@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.weid...@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. > > > > > > > > > >
