From: Justin D. <jde...@op...> - 2012-01-17 17:06:11
|
Hey Andrea, Thanks for the extended explanation. Makes sense. +1 on the approach, I think having the geometry_columns table for an override even when there is a geometry metadata table available makes sense. -Justin On Tue, Jan 17, 2012 at 9:22 AM, Andrea Aime <and...@ge...>wrote: > On Tue, Jan 17, 2012 at 3:47 PM, Justin Deoliveira <jde...@op...>wrote: > >> I can see adding the table to databases that have no notion of a geometry >> metadata table but adding when one already exists seems like kind of a >> workaround for this specific problem. But I could be totally wrong and >> perhaps this is a common issue... would have to delegate to actual oracle >> users on that one. >> >> > It's specific to the use case, but the use case is general (it's not > customer specific). > Let me elaborate again: > - the MDSYS views we are using are populated dynamically based on the > tables the current user can access, > you can only see what you own/can access > - we are doing impersonation so that the user can phisically access only > the data > he's allowed to by the database own security > - the pool user cannot access anything under a high security setup, only > dictionary tables, > as a result during GeoServer startup, while no user is setup, we decide > the srid of > the various geometries is -1 > - then someone tries to use the data, boom, spatial filters fail > > Long story short, it's not customer specific, it's specific to using > impersonation > and database level security, which is an interesting use case in some > enterprises > that are very database focused. > This is pretty much the same as the sql scripts to do impersonation, they > are general > enough that anybody can use them, but only these very db centric setups > would > have any use for it I guess. > > It's very high end, and uncommon for us, ugly to look at, but I assure you > these > folks look at us the same way for our insistence on not being able to work > with stuff specific to their db of choice and the set of library functions > they > built into their install ("the only thing that is reusable is what is > implemented > as a procedure/check in the db" mindset, which is understandable if you > have tens of different products implemented in different languages > accessing > your central database). > > It's a matter of deciding wheter we want to open up enough facilities to > have > this particular user community in, or not (as far as I can see it's a > little circle, > but interesting from different points of views, in particular attention to > security, > high data volumes, and ability to sponsor further improvements). > > >> To help me understand, in your case will the existing metadata tables be >> kept in sync at all? Or totally ignored? >> > > First check the geometry_columns table if available, then check the mdsys > views (pretty > much what we do for primary keys as well). > > Cheers > Andrea > > -- > ------------------------------------------------------- > Ing. Andrea Aime > GeoSolutions S.A.S. > Tech lead > > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584 962313 > fax: +39 0584 962313 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.youtube.com/user/GeoSolutionsIT > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ------------------------------------------------------- > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |