Jetspeed 2
  1. Jetspeed 2
  2. JS2-375

Database scripts broken on Oracle 8i

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0-M4
    • Fix Version/s: 2.1
    • Component/s: Assembly/Configuration
    • Labels:
      None

      Description

      Building with Oracle 8i breaks the build:

      org.apache.jetspeed.production.database.default.name=oracle
      org.apache.jetspeed.production.database.ojb.platform=oracle8i

      This used to be working at some point in time.
      Oracle 8i doesn't support the TIMESTAMP data type

        Activity

        Hide
        Ate Douma added a comment -

        Oh, well, sorry but I missed that discussion on the list.
        But I now reviewed both your problem as well as the solution provided by Krishna Kumar.

        First of all, your problem had nothing to do with this, but was caused by incorrect settings in your build environment.
        The failed sql statement you showed:
        [sql] Failed to execute: INSERT INTO PREFS_NODE VALUES(1,NULL,'',0,'/','2004-05-22 14:57:53.586','2004-05-22 14:57:53.586')
        is not from the Oracle specific populate-userinfo-for-default-psml.sql, but from the one for Derby.

        Anyway, I also looked at the solution Krishna Kumar proposed.
        Although it might "work" more or less, I don't find it a "proper" solution.
        Oracle8i simply doesn't support TIMESTAMP fields. Its finest time resolution is only 1 second!
        Simply replacing TIMESTAMP values with DATE values doesn't cut it for me.

        On Oracle8i the only way to store TIMESTAMP level time resolution is storing the millisecond representation itself.

        I've been developing and testing Jetspeed for over 2 years now using Oracle9i, so be assured it doesn't need any patching for that.

        Show
        Ate Douma added a comment - Oh, well, sorry but I missed that discussion on the list. But I now reviewed both your problem as well as the solution provided by Krishna Kumar. First of all, your problem had nothing to do with this, but was caused by incorrect settings in your build environment. The failed sql statement you showed: [sql] Failed to execute: INSERT INTO PREFS_NODE VALUES(1,NULL,'',0,'/','2004-05-22 14:57:53.586','2004-05-22 14:57:53.586') is not from the Oracle specific populate-userinfo-for-default-psml.sql, but from the one for Derby. Anyway, I also looked at the solution Krishna Kumar proposed. Although it might "work" more or less, I don't find it a "proper" solution. Oracle8i simply doesn't support TIMESTAMP fields. Its finest time resolution is only 1 second! Simply replacing TIMESTAMP values with DATE values doesn't cut it for me. On Oracle8i the only way to store TIMESTAMP level time resolution is storing the millisecond representation itself. I've been developing and testing Jetspeed for over 2 years now using Oracle9i, so be assured it doesn't need any patching for that.
        Hide
        Ralph Goers added a comment -

        I guess I don't understand. I experienced this problem and the solution provided by Krishna Kumar on the user's mailing list a few days ago worked for me. However, I am running Oracle 9i, not 8. So it seems this fix is needed for that release as well.

        Show
        Ralph Goers added a comment - I guess I don't understand. I experienced this problem and the solution provided by Krishna Kumar on the user's mailing list a few days ago worked for me. However, I am running Oracle 9i, not 8. So it seems this fix is needed for that release as well.
        Hide
        Ate Douma added a comment -

        I've thought some more about this problem and have come to the conclusion it's not worth it (to me at least) to try to support Oracle8i.
        Proper support would require using a different mapping of TIMESTAMP fields for Oracle8i alone like trying to store the long value of
        a TIMESTAMP and do some magic while loading/persisting using OJB conversion classes.
        Well, I think that's too much trouble for now, especially when you consider the age of Oracle8i.
        Who didn't upgrade yet to 9 or 10 already?

        But if somebody really still needs Oracle8i support, please let us know and I or someone else might reconsider spending some time on this.

        Show
        Ate Douma added a comment - I've thought some more about this problem and have come to the conclusion it's not worth it (to me at least) to try to support Oracle8i. Proper support would require using a different mapping of TIMESTAMP fields for Oracle8i alone like trying to store the long value of a TIMESTAMP and do some magic while loading/persisting using OJB conversion classes. Well, I think that's too much trouble for now, especially when you consider the age of Oracle8i. Who didn't upgrade yet to 9 or 10 already? But if somebody really still needs Oracle8i support, please let us know and I or someone else might reconsider spending some time on this.
        Hide
        Ate Douma added a comment -

        Delaying this issue to 2.0-POST.
        There isn't enough time left to look into finding a solution which could work on Oracle 8i (if even acceptable possible).

        Thus, Oracle 8i won't be supported for the Jetspeed-2.0-FINAL release (if ever).

        Show
        Ate Douma added a comment - Delaying this issue to 2.0-POST. There isn't enough time left to look into finding a solution which could work on Oracle 8i (if even acceptable possible). Thus, Oracle 8i won't be supported for the Jetspeed-2.0-FINAL release (if ever).

          People

          • Assignee:
            Ate Douma
            Reporter:
            David Sean Taylor
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development