[udig-devel] Database tables
Andrea Aime
andrea.aime at alice.it
Tue Jul 25 07:34:38 PDT 2006
Robbie Jameson ha scritto:
> Many thanks for this answer. As we are in a bit of a hurry I may have to opt
> for the database-side view option. Out of curiosity, does your own hibernate
> solution use actual geodatabase functionnality in the hibernate mapping
> implementation or are you in a pure ordinary hibernate mapping approach?
Heh, it depends on you. First, you have to implement user types so that
the geometries gets stored in the database using the actual geometric types
of the database. Second, you have to provide an sql encoder that is able
to encode the spatial filters the right way for your database.
This is pretty easy for postgis, oracle, mysql because the sql encoders
are basically already available in geotools (and you can reuse code
for making a usertype too).
You can define what your FEature looks like by using a class that closely
mimics the Hibernate Criteria, so you can do all the joins and projections
you like :-)
The downside if that you need to have beans already mapped onto the database,
so it's a good solution for applications that already have an hibernate
object model that they need to be visualized with geotools.
Oh, another problem at the moment is that the datastore is read-only (had
no time for the write part so far).
Cheers
Andrea Aime
More information about the udig-devel
mailing list