Re: [jira] Updated: (CAY-1282) Use #result as optional directive for only few columns (not all)

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon Oct 12 2009 - 03:30:04 EDT

  • Next message: Andrus Adamchik: "Re: [jira] Updated: (CAY-1282) Use #result as optional directive for only few columns (not all)"

    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



    This archive was generated by hypermail 2.0.0 : Mon Oct 12 2009 - 03:32:04 EDT