From: Alessio F. <ale...@ge...> - 2012-04-29 15:24:57
|
Hi guys, since I don't like to write a lot I will try to be very concise .... 1. As a PSC member and actual developer using heavily 2.2.x, I would like to have the warranty that this GSIP does not introduce any instability on the code before branching and having a release. As far as I understood this GSIP implies only API changes, so hopefully this won't impact the actual functionality of the catalog and GeoServer core. 2. Technically speaking: a) are we sure the Predicate is the best option? Why not using Generic DAOs? Do we have something already in place that performs filtering and pagination at lower level? b) I guess any extension to the catalog is nice but almost unuseful until we have everything in memory. We should envisage on such improvements the possibility of serializing/deserializing objects on the fly and introduction of Level 1 and possibly Level 2 Caching mechanisms. my vote for the moment is -0 on this GSIP, until we clarify some more things especially on a more longer term refactoring of the catalog. Regards, Alessio. ------------------------------------------------------- Ing. Alessio Fabiani Founder / CTO GeoSolutions S.A.S. GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: (+39) 0584 96.23.13 fax: (+39) 0584 96.23.13 mobile:(+39) 331 62.33.686 http://www.geo-solutions.it http://geo-solutions.blogspot.com http://www.linkedin.com/in/alessiofabiani https://twitter.com/alfa7961 http://twitter.com/geosolutions_it ------------------------------------------------------- On Sat, Apr 28, 2012 at 8:29 PM, Justin Deoliveira <jde...@op...>wrote: > 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 <and...@ge... > > 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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > |