Jukka, I'm responsible for the code the calculates the min/max extents for inserting/updating the USER_SDO_GEOM_METADATA view. This is supposed to only be run via ogr2ogr when loading/updating tables (I didn;t write that part, just the query to get those extents). There shouldn't be any updating going on in an ogrinfo call.
Personally, I do think that any calls against the ALL_SDO_GEOM_METADATA should really only go against USER_SDO_GEOM_METADATA. There were a couple of tickets about 2 years ago that implemented thee changes. I'll look them up and post the tickets. Mike -- Michael Smith US Army Corps Remote Sensing GIS/Center On 8/22/12 7:36 AM, "Rahkonen Jukka" <jukka.rahko...@mmmtike.fi> wrote: >Stefano Iacovella wrote: > > >>> I guess that meaning is to check all the metadata rows from the >>> ALL_SDO_GEOM_METADATA view which are referring to the queried table. >>> There can be several rows created be different Oracle users. Next the >>> maximum BBOX is constructed and that is updated into >>> USER_SDO_GEOM_METADATA view. > >> It seems to me that first statement should include an OWNER filter in >>the WHERE clause, or it will fetch all records for table with same name >>and same geometric filedname. > >Not really, it is normal in managed envinronment that db admins or data >managers are creating and updating the tables but reporting is done with >minimal rights. So reading ALL_SDO_GEOM_METADATA does make sense. And >actually USER_SDO_GEOM_METADATA is a view into the same data than >ALL_SDO_GEOM_METADATA filtered by the current username. Oracle holds the >data in a real table named mdsys.sdo_geom_metadata_table but users cannot >handle that table directly, everything goes through views and triggers. > >I do not know if it makes much sense really to have several metadata rows >with different owners in the metadata table but it happens and it must be >done sometimes. Some programs do not even try to read >ALL_SDO_GEOM_METADATA. That means that developers have not worked too >much in a real production environment and they are creating their test >tables with some Oracle admin account and then they are reading the data >with their clients with the same admin account. Bad habbit but totally >understandable, it is much faster and easier so. It is OK but before >finalizing with coding it would be good to make a test: What if I try to >do this with limited rights? It would be good also to write it into >documentation what rights and into which tables are needed. Policy in >our house is that a non-admin Oracle user has by default no rights to do >anything. Everything must be explicitly granted. Now we have usually >learned by trial and error by adding grants one by one and following what >is blocking us next. > >-Jukka Rahkonen- > > >Regards > >stefano >--------------------------------------------------- >41.95581N 12.52854E > > >http://www.linkedin.com/in/stefanoiacovella > >http://twitter.com/#!/Iacovellas >_______________________________________________ >gdal-dev mailing list >gdal-dev@lists.osgeo.org >http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev