Interface Change

There is a new public Interface IVistaDBTableList - this is used as an experiment to extending the DDA interface to include strongly typed members.  This interface gives you the ability to get back a strongly typed version of the EnumTables through a function called EnumTablesTyped().  This will return an IVistaDBTableList that may be used in a foreach loop for faster handling without casting, and contains optimized lookups for contains, etc. Here is an example.

 IVistaDBDatabase db = DDAUtils.BuildTestDatabase(ref DDAObj, dbname, false, null, false); 
 IVistaDBTableList tableList = db.EnumTablesTyped();
 foreach (string table in tableList)
 {
    Console.WriteLine("Table is named: " + table);
 } 

CLSCompliant - Tagged IVistaDBTableList members as false

This is mostly an experiment at this point, and this interface may go away in the final build of 3.4.  The one major drawback is that the interface has to expose an unsigned long value - this makes us tag that interface and the function and non CLSCompliant.  I am not too happy about that, but the TableID is an unsigned long, so how else would you expose it?

Internally the VistaDBTableList is used now for getting and testing all table lists.  The performance on this compared to the older ArrayList version is amazing.  For some complex table layouts the performance of the new strongly typed class more than twice as fast.  See the recent blog post about strongly typing everything!

We need to think about how to expose these types of interfaces through an API without losing the CLSCompliance flag. 

I wonder how others are handling this? I have a feeling for the final 3.4 release we will probably have to hide all the unsigned long variables in order to keep our clean interface CLSCompliant.

On the one hand keeping everything CLSCompliant is a good idea for an API, and makes it much easier to run in low / medium trust environments.  On the other hand when you have a legitimate need to expose more than an Int64 to the world how would you do it?