[gdal-dev] When and why ogrinfo sends update for Oracle?

Smith, Michael ERDC-RDE-CRREL-NH Michael.Smith at erdc.dren.mil
Wed Aug 22 06:03:06 PDT 2012


Jukka,

Actually, it doesn't matter since only one value is used in the query, min
or max return the same result. Its just using the min function with the
group by to aggregate the values into one row. All the other values are
null.

Mike

-- 
Michael Smith

Remote Sensing/GIS Center
US Army Corps of Engineers

 

On 8/22/12  8:41 AM, "Rahkonen Jukka" <Jukka.Rahkonen at mmmtike.fi> wrote:

>Hi,
>
>This part of query takes UB min values as maxx and maxy. Wouldn't it be
>better to select the max values instead?
>min(case when r=1 then sdo_ub else null end) maxx, min(case when r=2 then
>sdo_ub else null end) maxy
>
>-Jukka-
>
>Smith, Michael
>
>> 
>> 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.Rahkonen at 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 at lists.osgeo.org
>> >http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>_______________________________________________
>gdal-dev mailing list
>gdal-dev at lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/gdal-dev



More information about the gdal-dev mailing list