You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by "Andrus Adamchik (JIRA)" <de...@cayenne.apache.org> on 2007/06/27 21:01:34 UTC

[JIRA] Created: (CAY-813) SQLTemplate improvement: #column directive

SQLTemplate improvement: #column directive
------------------------------------------

                 Key: CAY-813
                 URL: https://issues.apache.org/cayenne/browse/CAY-813
             Project: Cayenne
          Issue Type: Task
          Components: Cayenne Core Library
    Affects Versions: 3.0
            Reporter: Andrus Adamchik
            Assignee: Andrus Adamchik
             Fix For: 3.0


When testing EJQBL query on PostgreSQL, I noticed that the result padded CHAR columns are not trimmed. A DbAdapter would install an ExtendedType that implements column trimming behavior appropriate for the target DB. In case of EJBQL query (that is internally translated to SQLTemplate), the ExtendedType didn't have enough information about the column to make a trim/no-trim decision. The missing piece is JDBC type. 

Column information is passed to Cayenne via #result directive in SQLTemplate... It has java class parameter, but not JDBC type parameter. I am thinking of redesigning the #result directive into a more usable variety, that addresses this concern, and other #result limitations. To address backwards compatibility concerns, instead of redefining #result, I would suggest  a new directive called #column:

#column(index javaType)
#column(index javaType jdbcType)
#column(index javaType jdbcType rowLabel)

An example:

   SELECT t0.ARTIST_NAME as C1, t0.DATE_OF_BIRTH as C2 #column(2 'java.sql.Timestamp' 'TIMESTAMP')

The advantages:

* It solves the main limitation of the #result - the need to tag ALL columns (so it will require backend support for partial result set descriptor that is filled in from metadata on the fly), 
* it doesn't require the SQL column alias to be teh same as DataRow value key.
* It can appear anywhere in the SQL, not necessarily tied to the SQL column declaration, so "SELECT * #column(3 'String') FROM..." is valid.
* It supports JDBC type parameter, letting adapter to make the right decision on the value handling (the original motivation for the new directive).


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.