Hi, If I do ogrinfo with "--debug on" against Oracle l can see updates for USER_SDO_GEOM_METADATA. Same happens if I do ogr2ogr with output to for example GML. For me is seems not to happen only with loading and updating. I have not an easy access to Oracle logs and I have studied only the OGR debug messages on my screen.
-Jukka Rahkonen- Smith, Michael wrote: > > 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