> It doesn't matter how this represented *inside* the builder class, as > builder is used only once per query. On the other hand, coming out of the > builder it must be optimized, as access to the column descriptors array is > performed N*M times during each result set processing, where N is the width > of the result set, and M is its length. I.e. it can be a very large number > (up to tens or hundreds of millions calls). Every small optimization matters > here.
So.. I was talking exactly about optimization... HashedSet array can be faster cause we perform several scans over whole array of ColumnDescriptors. And safety cause we don't get duplicates for Columns. And.. I didn't get you position about this idea > This is something I don't know. We need to check about a dozen of drivers > from different vendors that we support to verify that. This is just a getter > in the interface. Implementors could've made it anything. I have looked through JTDS drivers (not a dozen but a least one). ResultSet has all information about columns (just private final ColInfo[] columns). When getMetaData performed - constructs new Object that has reference to array of columns from ResultSet . Looks like there is no problem with JTDS. >> The problem that if we don't set ResultSetMetadata like in current >> (trunk) version, without ResultSetMetadata we don't know all >> columns.. > > Not true. We don't know all the columns for SQLTemplate queries. For all > other types of queries we DO know all the columns, as Cayenne generates SQL > from scratch for those queries. I think this one place is where we have the > biggest mismatch in our views of the implementation. ah... now I see. You are right that was a mismatch in our views. I will work on it in the evening. > Another thing to check here is actually reading column data from returned > ResultSetMetadata, as lazy > resolving of it can be postponed a step further. Again in JTDS it's just a array of ColInfo (like our ColumnDescriptor), it's passed to RowSet through constructor from protocol implementation. Evgeny Ryabitskiy.
