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 <[email protected]>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 <[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
>
>
------------------------------------------------------------------------------
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
