As far as I can tell from the source code, it seems that the locking of
features is completely implemented in java and not in the database.
Wouldn't it be better, to implement locking in the database through the
data source? Especially for somebody that wants to use geoserver just as
an additional front-end to a common database. i.e. non-wfs clients and
wfs clients are accessing the data concurrently.
Yes, you are exactly correct. We are working on that functionality right
now. Most of the work is in geotools, we've done away with
TypeRepository. Most of the work is in the data module of geotools. The
locking functions are mostly in org.geotools.data.FeatureLocking. They
use a locking manager, with the default being an InProcessLockingManager,
which is like the TypeRepository, all java. The PostgisLockingManager
should be along soon, working with Postgis 0.8 when it comes out, as
Refractions added new locking backend locking methods. ArcSde and Oracle
will also be supported in time. It's a bit trickier than it looks at
first, since the wfs notion of locking is a bit different than most db's
notions.
Another question concerning the TypeRepository.
org.vfny.geoserver.config.TypeRepository is a concrete class. It loads
the type information from info.xml and the corresponding xml schema from
schema.xml. This is a fairly specific setup. We would want to load this
information from the database. Shouldn't there be an interface that
defines the basic methods every TypeRepository must implement and
implementing classes that define a custom TypeRepository? Just to remove
the dependency from a specific implementation...
Hmmm, that's an interesting point. We're redoing configuration right now.
We've got a lot of changes going on in the wms-merge, making room for the
new geotools data io apis. The replacement for TypeRepository is
org.geotools.config.CatalogConfig. The way the configuration will work is
that you define your connection parameters in catalog.xml, defining your
DataStores, and then each FeatureType will reference the its DataStore to
get its connection. The locking methods of TypeRepository move to
geotools LockingManagers. As for schema.xml, where we would eventually
like to go is have datasources automatically generate their schemas.
They do this now, making geotools FeatureTypes, but we can not turn those
into XML Schemas yet. The geotools FeatureTypes also need some
improvement before we can do that. Jody Garnett is planning on spending
the next two months or so on configuration, and I think he also wants to
split things up a bit more. So what you should do is look at the new
configuration (which is still evolving), and come up with a concrete
proposal of how you'd like things split up. If possible you can code up a
new set of interfaces, and we could easily roll the changes in. Perhaps
Jody has more thoughts on this issue? You should probably collaborate
with him and get his ideas on configuration, and figure out a way to fit
loading config files from other sources into his plans.
hope this helps,
Chris
Sincerly
Simon Räss everything correctly.
As far as I can tell from the source code, it seems that the locking of features is completely implemented in java and not in the database. Wouldn't it be better, to implement locking in the database through the data source? Especially for somebody that wants to use geoserver just as an additional front-end to a common database. i.e. non-wfs clients and wfs clients are accessing the data concurrently.
Another question concerning the TypeRepository. org.vfny.geoserver.config.TypeRepository is a concrete class. It loads the type information from info.xml and the corresponding xml schema from schema.xml. This is a fairly specific setup. We would want to load this information from the database. Shouldn't there be an interface that defines the basic methods every TypeRepository must implement and implementing classes that define a custom TypeRepository? Just to remove the dependency
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--