Not much to comment on except that however the implementation decides to do
storage I see purely an implementation detail. As long as the api doesn't
force in any way or make an assumption about storage we should be fine. The
fact that the current jdbc implementation is done this way stems from the
fact that the original implementation was bdb where this key value blob
style makes more sense, and the idea was to get a quick jdbc prototype up
and running. Ideally someone steps up with a nice implementation for jdbc
that does a mapping to a pure relational model. There is also the dbconfig
module to take into consideration. Given a choice of implementing it over I
would say away from hibernate but that said there is some good code there,
could be an easy pick up for someone who knows hibernate.
On Sat, Apr 28, 2012 at 3:00 PM, Andrea Aime
<[email protected]>wrote:
> Last one about the serialization subsystem.
>
> The idea of storing all the elements in text/binary blobs is not new
> (DeeGree actually does that to handle complex features, only making
> some of the attributes explicit, those that the admin thinks is going
> to be used as filters), and I fully agree it maps well to key/value
> nosql databases, as well as any db that has first class support for
> xml and json and allows to do direct searches on it.
>
> Doing that in a relational BDMS is clunky though, for a variety of
> reasons, but I agree it's a quick way to get a R-DBMS catalog working
> (though.. say goodbye to spatial filtering, which is not good at all).
>
> Ah, about the ability to filter and me not seeing PredicateToSQL,
> I actually saw it and went over it a few times, what I did not
> see was the exporting of attributes in the second table and the
> usage while building the sql.
>
> To my defense, how can you guess that the "relations" table is
> actually exported attributes from a bean? The naming makes no sense to me:
>
> CREATE TABLE CATALOG (id VARCHAR(100) PRIMARY KEY, blob bytea);
>
> CREATE TABLE DEFAULTS (id VARCHAR(256) PRIMARY KEY, type VARCHAR(100));
>
> CREATE TABLE RELATIONS (id VARCHAR(100), type VARCHAR(50), relation
> VARCHAR(256), value VARCHAR(4096));
>
> The code of the PredicateToSQL is rather criptic, and does a lot of string
> manipulation, a standard OGC filter encoder seems actually simpler.
> Now that I know it's exporting attributes and encoding searches on them
> I still have a hard time imagining how the actual query to the database
> looks like, though it seems to be something with one subquery for each
> queried property, something like
> "select blob from catalog where id in (suquery1) or id in (subquery2) or
> ..."
>
> However, if it works, it works, the problematic point will be
> selling it to the db admin that manages the database cluster sitting
> behind GeoServer in a HA setup, and the people wanting to interact with the
> database.
>
> Now, you might rightfully say that you don't care and that they are free to
> implement their own.
> On the other side, I believe the current in memory catalog will keep on
> fitting
> most simple installation needs (100-1000 layers).
> Installations that have lot more and are setup for multitenancy will likely
> be fully HA and have the dreaded db admin looking at the schema and
> indexes.
> People that want to publish new layers and hope to use the familiar SQL
> commands
> will also be disappointed as we turn them to REST config.
>
> Which leaves the proposed implementations for those green field
> installation or
> places where the db admin actually does not mind seeing the db used as a
> key/value
> store.. that is, what looks like a relatively narrow use case.
>
> Justin makes a good point about transactions handling in a
> servlet/dispatcher filter,
> I agree it's a good idea, something that we should add and that would also
> reduce to zero the need for the existing config locks. How hard would it
> be to wire
> the catalog trasaction handling with the typical Spring filters for
> transaction management?
>
> Long story short, the persistent implementations that good community
> modules meant
> to demonstrate the feasibility of doing secondary storage catalog
> implementations.
> Not happy about how the jdbc one looks, but they serve the need of showing
> multiple
> implementations just fine.
>
> Cheers
> Andrea
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
