Changes between Initial Version and Version 3 of Ticket #11706


Ignore:
Timestamp:
Aug 17, 2009, 10:40:50 AM (15 years ago)
Author:
Matt Boersma
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #11706

    • Property Triage Stage Unreviewed → Accepted
    • Property Summary Use of RETURNING means Oracle 9i is no longer supported → Use of RETURNING should be optional

  • Ticket #11706 – Description

    initial v3  
    1 See closed ticket #10473.  The "RETURNING...INTO" SQL construct is supported only in Oracle 10g and later, so effectively Django 1.1 will no longer work on Oracle 9i because INSERT statements will fail with "ORA-22816: unsupported feature with RETURNING clause."
     1See closed ticket #10473.  The "RETURNING...INTO" SQL construct is supported in Oracle versions 9i and later, but with some significant restrictions:
    22
    3 Oracle 9i is quite old and no longer actively sold or available for download from www.oracle.com (11gR1 is current).  However, if you know Oracle shops, they aren't often aggressive about upgrading--where Ian and I happen to work is one example of this.  So I see three solutions:
    4 1) Fall back to the old, compatible code that didn't use RETURNING
    5 2) Make the use of RETURNING optional, conditional on server version
    6 3) Correct the docs to say that Oracle 10g and later are supported in Django 1.1
     3{{{
     4Oracle Error :: ORA-22816
     5
     6unsupported feature with RETURNING clause
     7Cause
     8
     9RETURNING clause is currently not supported for object type columns, LONG columns, remote tables, INSERT with subquery, and INSTEAD OF Triggers.
     10Action
     11
     12Use separate select statement to get the values."
     13
     14 at least in version 9isupported only in Oracle 10g and later, so effectively Django 1.1 will no longer work on Oracle 9i because INSERT statements will fail with "ORA-22816: unsupported feature with RETURNING clause.
     15}}}
     16
     17The use of RETURNING INTO isn't mandatory, so perhaps we could refactor it so a settings.py option turns it off.  Our use case is an in-house application that has several INSTEAD OF triggers.
Back to Top