Re: [jira] Commented: (CAY-1323) oracle.sql.TIMESTAMP in Result of query

From: Evgeny Ryabitskiy (evgeny.ryabitski..mail.com)
Date: Wed Dec 02 2009 - 12:25:41 EST

  • Next message: òÑÂÉÃËÉÊ å×ÇÅÎÉ: "Cayenne Oracle tests"

    Ok. Now it is much clear. Thx for explaining.

    Evgeny.

    2009/12/2 Andrus Adamchik <andru..bjectstyle.org>:
    > Hi Evgeny,
    >
    > Let me take this to dev... Thanks for providing all the information on the
    > issue and working on the fix. This is rather valuable to Cayenne, as your
    > system has a number of use cases that seem to be pretty unique in this
    > community, and you can find things that nobody else will. (Also hope that
    > your Apache account will be created soon, so that you can take over this
    > Jira and commit it yourself)
    >
    >> As you wrote: "Cayenne Mapping can only contain JDBC types"
    >
    > Let me clarify. This was referring to the DB part of the mapping. On the
    > Java part we can map any custom types. And we do in fact. Cayenne is
    > definitely not limited to the types listed in the JDBC spec, again on the
    > object end of the mapping.
    >
    >> How to fix... mm have thoughts that OracleAdapter can help us... need some
    >> time to look there inside
    >
    > Yes please.
    >
    > Let me comment on the fix versions to avoid misunderstanding. The fix
    > versions will depend on the nature of the fix and the definition of the
    > problem. Just returning an Oracle type from an unmapped query is IMO not a
    > bug (actually it looks more like a bug in Oracle driver from your examples,
    > and what I found via Google). On the other hand returning correct value from
    > SQLTemplate with an explicit #result(), is something that we need to handle
    > correctly ourselves.
    >
    > So the second case should probably be fixed on all stable branches.
    >
    > The first case would require us to redefine how Cayenne works. For instance
    > we may decide that from 3.1 all Oracle internal types should be converted to
    > JDBC default types (unless otherwise specified by the user). But we won't be
    > able to include that change in the "stable" releases.
    >
    > Andrus
    >
    >
    > On Dec 2, 2009, at 6:16 PM, Evgeny Ryabitskiy (JIRA) wrote:
    >>
    >>   [
    >> https://issues.apache.org/jira/browse/CAY-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784887#action_12784887
    >> ]
    >>
    >> Evgeny Ryabitskiy commented on CAY-1323:
    >> ----------------------------------------
    >>
    >> I think I finished my Investigation. If you wish I can add some JUnit for
    >> this UC.
    >>
    >> You can add "Fix Version" as you wish. But I think it should be fixed in
    >> all branches (1.0, 2.0, 3.0).
    >> It is no expectable behavior.... As you wrote: "Cayenne Mapping can only
    >> contain JDBC types"
    >>
    >> How to fix... mm have thoughts that OracleAdapter can help us... need some
    >> time to look there inside
    >>
    >>> oracle.sql.TIMESTAMP in Result of query
    >>> ---------------------------------------
    >>>
    >>>               Key: CAY-1323
    >>>               URL: https://issues.apache.org/jira/browse/CAY-1323
    >>>           Project: Cayenne
    >>>        Issue Type: Bug
    >>>        Components: Cayenne Core Library
    >>>  Affects Versions: 2.0.5, 3.0 beta 1
    >>>          Reporter: Evgeny Ryabitskiy
    >>>          Assignee: Andrus Adamchik
    >>>       Attachments: cayenne.xml, OracleTimestampTest.java,
    >>> OracleTimestampTestMap.map.xml
    >>>
    >>>
    >>> Result of query from column of timestamp type was mapped to
    >>> oracle.sql.TIMESTAMP.
    >>> I think it should be mapped to standard JDBS TIMESTAMP
    >>> I am using latest official Oracle JDBC driver.
    >>
    >> --
    >> This message is automatically generated by JIRA.
    >> -
    >> You can reply to this email to add a comment to the issue online.
    >>
    >>
    >
    >



    This archive was generated by hypermail 2.0.0 : Wed Dec 02 2009 - 12:26:16 EST