The complex datastore branch is not complete, and the current plan is
that the FM branch will take over the functionality. The problem with
the complex branch is that it didn't have a migration path to get on to
trunk, it just had a new way of doing things.
And the main goal of the branch was really to get complex output, not
just to do joins (though joins is definitely an extremely importan part
of it).
Does your new datastore work with the current geotools feature model, or
the one on the complex datastore? Like are you mapping to nested
attributes, and things like choice? Or do you just map from the join
statement to the current flat geotools feature?
If you're just using it against the current geotools feature model (like
a released 2.x series), then it might be valuable to just have yours as
an option for people. We could then later add the ability to map to
more complex attributes, if it's not already there.
best regards,
Chris
Antonio Grassi wrote:
Hi. I've read the message about complex datastore. At work we've have
similar problems. In our case we wanted to join variuos tables in
postgres+postgis. We implemented a new datastore, defining the layers in
xml and mapping the layer attributes to specific tables and attributes,
the tables to join, etc., and it works at least in the situation you
specify. In the future we also wanted to compose layers using data from
different datastores. The code is quite unreadable and in a lot of
places it's specific to how the things are done here. Anyway, it was
quite easy to implement, we had to extend only a couple of classes, and
because we were working in one single DB the problem was primary to
build the correct SQL querys and map results to the layer attributes.
We've been following the progress of the ComplexDataStore, and last
month we tried to use it with no results; I must say we didn't try more
than a day. We expected to replace our implementation with that of the
complexdatastore in the nearby future, as we see that certain things
require new implementations and extensions of other things. In another
mail sent about this subject, it was not clear for me if complex is a
mess, etc., because it's in the primary stages or because definitively
it wont be worked on anymore. It would be great if someone with
knowledge about the actual state of the branch could be more specific
about the status of the complexdatastore.
Well, thanks,
Antonio
!DSPAM:1003,4500009d164562223018498!
------------------------------------------------------------------------
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
!DSPAM:1003,4500009d164562223018498!
------------------------------------------------------------------------
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
!DSPAM:1003,4500009d164562223018498!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
