Skip to content
March 21, 2007 / Steven Pousty

Turbocharging GeoDB interactions

Some of the geodatabases uses different providers and some geodb object care about teh provider of the data

Object class properties
There are 4 methods that control it’s behavior – he is covering the methods you need to implement or that you can use to query an object to understand it’s geodb behavior. You ask questions of the feautre classes to see this. Care about this espwcially if you write a featureClass extension. You can only tighten a policy but not loosen.

Validating Data
Why we allow invalid data when loading?
Do not want it to disappear when loading – some storage representation allowed invalid geometries.
The goal is to keep data and then have you go look for bad stuff.

How to validate
Ephemeral topologies – keep it only QAQC but it is not permanent in the dataset
Validation rules
Class extensions – they can do validation checks
You can also catch things that are editor events.

When to validate
After loading but PRIOR to versioning but if you miss that
After loading but PRIOR to other users creating new versions off default – if you miss that
Before posting edits to Default (QA version)

There is an ivalidate API I validation interface – it is a quick abort logic – first error all done
The order to validation is subtype, attribute rules, network connectivity, custom rules (class extension), and then relationship rules.

How to do
IObjectClassExtension fill in the validate method (I think)

Dataset extensions
Class extensions and workspace extensions
Internal Arch. pattern for adding new datasets types to geodatabase
No need to touch GDB kernel, examples are network datasets, terrain datasets, representation classes, cadastral fabrics.

Can’t make your own but it changes how you work with the data – simplified end user access pattern. Navigation becomes generic, no need to use dataset type specific interfaces


Slide of code that is hard to see.

Schema updates and creation – don’t use names but instead use a data elments which was grown out of geoprocessing. Once you populate this object with properties you then pass it into factory which gives you the dataset. This pattern will become significant to GEODB users in the future. Get comfortable with it…

Feature events and class extension events only appl to custom classes but other events are just fired

Example IRowEvents
OnChange – first functionality called in Store()

There is a chain of calls – you need the slide and you should think of this if you want your code to be called somewhere particular in the chain of events fired on a store event.

IObjectClass[Schema]Events – when you change the behavior of a feature class – add an object class extension or make something participate in a topology.

There are also events if you write a feature class extension that let’s you know if a relate class changes

He is covering a lot and it is hard for me to get it all here so I may switch my narrative mode….

There are ItopologyClassEvents for validation and it gives you all the areas that were validated.

There are also workspaceEditEvents – start or stop editing events and undo redo stuff

There are also IWorkspaceReplicaEvents which gives an event before and after creating children

There are IVersionEvents with things like OnReconcile or OnConfilctsDetected.

IVersionEvents2 which are added at 9.2

Cursors againRows created by class cursor are bound to the class that created the cursor – queryDef is not bound to any class so you can create joins.Search Cursors:
When in an edit session the query may actually just go to the cache and not be reconciled . A search cursor flushes the editor before doing your search.Update Cursor:
NextRow -> updateRow -> NextRow….
Update cursors are never satisfied by the cache and it will also flush the cache.
If class support Store events then under the hoods it is an update cursor. The UpdateRow Method – if you call it on a row that was not just retrieved the from the cursor you are hosed. Don’t do it!

Insert Cursor:
Best performance when using buffering and proper flushing. Crucial to InsertRow and Flush have the proper error handle since both can result in rows written to teh database.
Flush frequency is a tradeoff with performance vs your tolerance for how much data you want to redo on error
!!Try to ensure that class has no spatial class – extra processing is required with a cache since it is synchonizing the cache with the inserts to the geodb
There are two sets of buffers – one in your client and one on the workspace

QueryDef cursor

They bypass any row cache
Call an evaluate and you will call all rows for all classes to flush – same as stopEditOperation
They do not support editing of the rows.

Cursor Recycling
It reuses data structures for the row and so you better not try to pass it around
Recycling is asuggestion not a guarantee – they may not be able to give it – but assume you are going to get one
More of the same from yesterday.
It can save you a bunch of memory because the geodb does it’s own caching and recycling lets it use the cache.

Non-recylcing cursors, subfields, and editing
!!They may overide the subfield of a query filter to create a nonj-recycling cursor resulting in all field being fetched because of the caching. If the class is being edited then it won’t allow subqueries.

Cursor scope

don’t hold cursors if you don’t need them – scope the cursor to edit operation not edit sessions.

More facts – see the slide when it is published since there is a lot of text:
Use getrows rather than getRow in a loop
Search Cursors are favored for editing.

Map Caches are important to know and make sure understand all the ins and outs.

GEODATABASE Selection Sets

These are not arcmap selections it is an object that references a set of rows by object ids – it is bound to a class, you can add and remove ids, you can query the selection set

IDSet – object ID reference not guaranteed to remain in memory
Snapsot – we guarantee that they are stored in memory
hybrid – it starts out snapshot but based on a threshold it will transition to IDSet

AllIds, onlyOne, or Empty if you want to fill it yourself

Best practices – if you are doing a combine operation create it as an IDSet
Extracting object ids only – use an ID enumerator rather than a search cursors

Avoid the use of hybrid selection type if you the size is larger than the transition – default is 100. So if you know it will be less than go with snapshot but if you know it is more then use IDSet becuase to transition is two different queries.

Favor AddList over add since it is better to add the whole collection. If you know the list of ObjectIds then create an empty selection set and then calls addlist of the ids rather than doing a search with a “IN ” filter with a list of IDs

Unique Instancing of Objects

Geodb objects that will have at most one reference

!!Within an edit session your row will be unique instance otherwise no


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: