On Oct 12, 2009, at 12:38 AM, Evgeny Ryabitskiy wrote:
If we talking about re-factor... I really wish to rewrite there
everything to use some Collection.. like ArrayList... or maybe even
HashSet.
In that case I can use just really fast hashed contains() method
instead going through all array of columns.
So.. collections is more safe, is much more flexible in code. And in
some cases even faster. I think usage of simple arrays is deprecated
since Java 1.5
But it's huge patch.. to change every ColumnDescriptor[] on some
Collection<ColumnDescriptor>. So.. what do you think?
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.
I think usage of simple arrays is deprecated since Java 1.5
This is most certainly NOT true.
3. The patch merges 2 strategies for creation of columns descriptor
into
one, that requires access to ResultSetMetadata. I am not sure that
ResultSet.getMetaData() is a trivial operation for all JDBC drivers
that we
support. I suspect there may be overhead accessing this data at
least on
some DBs. While we can verify this theory.
Yeah.. we should verify it, but I think ResultSetMetadata is formed
when result is returned.. anyway.. It's just a getter... do you think
ResultSetMetadata is "lazy" initialized?
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.
So maybe preserve the flow in RowDescriptorBuilder, and use your
strategy
merging explicit and implicit column descriptors *only* when an
optional
metadata object is initialized?
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.
Andrus
