Time to drop support for Oracle < 11?

[Tim Graham]

Hi Shai and Oracle users,

I came across a ticket (#11580) which proposes a fix that works on Oracle > 11 but not for older versions along with the suggestion: "Perhaps it makes sense to abandon support for Oracle versions below 11g in Django 1.6 or 1.7.".

I looked up the support dates from Oracle:

Release - GA Date - Premier Support Ends - Extended Support Ends

11.1 - Aug 2007 - Aug 2012 - Aug 2015
10.2 - Jul 2005 - Jul 2010 - Jul 2013
10.1 Jan 2004 - Jan 2009 - Jan 2012
9.2 Jul 2002 - Jul 2007 - Jul 2010

http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf

According to our docs:
Django supports Oracle Database Server versions 9i and higher. Oracle version 10g or later is required to use Django’s regex and iregex query operators.

Is it time to drop support for versions of Oracle that are no longer supported?

[Shai Berger]

Hi Tim and all,

On Saturday 14 June 2014 03:52:57 Tim Graham wrote:
>
> Release - GA Date - Premier Support Ends - Extended Support Ends
>
> 11.1 - Aug 2007 - Aug 2012 - Aug 2015
> 10.2 - Jul 2005 - Jul 2010 - Jul 2013
> 10.1 Jan 2004 - Jan 2009 - Jan 2012
> 9.2 Jul 2002 - Jul 2007 - Jul 2010
>

> According to our docs
> <https://docs.djangoproject.com/en/dev/ref/databases/#oracle-notes>:
> Django supports Oracle Database Server <http://www.oracle.com/> versions 9i

> and higher. Oracle version 10g or later is required to use Django’s regex
> and iregex query operators.
>
> Is it time to drop support for versions of Oracle that are no longer
> supported?

Heh. I tried this one myself, 2.5 years ago:
https://groups.google.com/d/msg/django-developers/SQ0Pltt_f0M/-h0jvJc5p1cJ

Unlike ikelly at that time, I'm not aware of people still using Oracle 8 or 9,
but reports about Oracle 10 were still received not too long ago (e.g.
https://code.djangoproject.com/ticket/20292 includes a report by an Oracle 10
user from a year ago). I don't want to pull rugs from under these people's
feet, if they are still out there.

On the other hand, neither me personally nor the Django project, as far as I'm
aware, have access to any of the versions you listed (not even 11.1); we can't
really commit to supporting them when we can't test against them.

So the approach I'd take is not to drop support altogether, but declare these
versions supported on a "best effort and community support" basis -- which
means a change in documentation, but not really in code. As a matter of
policy, I wouldn't knowingly make a change which breaks Oracle 10 support, but
I can't detect or solve such problems (if they crop up) without actual users'
help.

I'll want to hold this position, and add improvements under "if
ora_version>=11", until it becomes unwieldly, or a longer time has passed
since the last Oracle10 user report. I'd consider it for 1.8, but not sooner.

Shai.

[Josh Smeaton]

Personally we use oracle 11g (with a plan to move to 12c within the next year), but it wasn't that long ago that we were still using 10g. We're a smaller company that is able to upgrade our database without significant impact, but I'm betting (and guessing..) the vast majority of oracle users aren't.

I think Shai raises a good point - testing against the various versions of Oracle is very difficult. Is there anyway we can fix that? What version of oracle is used by CI for testing? And is there a way we can get some different versions of oracle working with the CI? Further, how are the various versions of other database backends validated? If we can apply the same or similar methods I think we'll be able to be in a better position to claim support for particular versions.

As for the suggestion of "if ora_version >= 11" - I think that'd be a fine interim solution, but it doesn't really address the problem.

Josh

[Ian Kelly]

On Fri, Jun 13, 2014 at 7:40 PM, Shai Berger <sh...@platonix.com> wrote:
> Hi Tim and all,
>
> On Saturday 14 June 2014 03:52:57 Tim Graham wrote:
>>
>> Release - GA Date - Premier Support Ends - Extended Support Ends
>>
>> 11.1 - Aug 2007 - Aug 2012 - Aug 2015
>> 10.2 - Jul 2005 - Jul 2010 - Jul 2013
>> 10.1 Jan 2004 - Jan 2009 - Jan 2012
>> 9.2 Jul 2002 - Jul 2007 - Jul 2010
>>
>> According to our docs
>> <https://docs.djangoproject.com/en/dev/ref/databases/#oracle-notes>:
>> Django supports Oracle Database Server <http://www.oracle.com/> versions 9i
>> and higher. Oracle version 10g or later is required to use Django's regex
>> and iregex query operators.
>>
>> Is it time to drop support for versions of Oracle that are no longer
>> supported?
>
> Heh. I tried this one myself, 2.5 years ago:
> https://groups.google.com/d/msg/django-developers/SQ0Pltt_f0M/-h0jvJc5p1cJ
>
> Unlike ikelly at that time, I'm not aware of people still using Oracle 8 or 9,
> but reports about Oracle 10 were still received not too long ago (e.g.
> https://code.djangoproject.com/ticket/20292 includes a report by an Oracle 10
> user from a year ago). I don't want to pull rugs from under these people's
> feet, if they are still out there.

I'm pretty much out of the Oracle fold at this point, so I don't know
either how common these installations still are. A stackoverflow
search for "[oracle9i]" shows that several new questions per month are
still being asked there. "[oracle9i] [django]" is looking pretty
empty, though.

My only comment at this point is that if support is to be dropped,
#11580 doesn't make a particularly strong case for it since running an
icontains query on a TextField isn't going to scale well and probably
isn't a good idea to start with.

[Tim Graham]

It seems to weird to claim (even best-effort/community) support for a database that is no longer supported by its authors. Also, you can always use an older version of Django, right? I tend to think you're probably not interested in the latest and greatest Django if you're using a really old database. My general proposal (for all databases) would be to drop support for a database version in the Django release that follows its end-of-life date.

Regarding testing, Oracle is currently not on CI, but Shai and I are working to add support for 11 and 12. This would actually be the only database where we have testing for multiple versions. For the other databases we are using whatever version Ubuntu 12.04 ships with (PostgreSQL 9.1.13, MySQL 5.5.37).

[Aymeric Augustin]

On 14 juin 2014, at 14:40, Tim Graham <timog...@gmail.com> wrote:

> My general proposal (for all databases) would be to drop support for a database version in the Django release that follows its end-of-life date.

That’s also my position. It applies to all dependencies of Django, even Python.

I find it irresponsible to advertise support for software that no longer receives security updates.

--
Aymeric.

[Marc Tamlyn]

Not much to add, just that I agree with Tim and Aymeric. We cannot and should not claim to support database versions which are no longer supported by their authors and do not receive security updates.

That's not to say we should actively break support for old databases if they happen to work, but we should remove any conditional code we might have regarding them and we should not consider them when adding new features.

Marc

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/D89DCE98-6891-4EF5-9A04-34D3F8FC2BEE%40polytechnique.org.

For more options, visit https://groups.google.com/d/optout.

[Shai Berger]

Hi guys,

TL;DR -- ...sorry, there's no TL;DR here. It's a bunch of separate ideas. It's
a little lengthy. Please bear with me.

I'd like to compare our support for old database servers with our support
for old browsers. We only recently dropped code that supported IE 6/7 (!)
for a security (!) fix, and even that decision wasn't taken trivially. I don't
think suggestions that will break Django sites for IE8 users will be
appreciated, unless there is a great benefit on the other side. And IE8,
along with the OS which required it, are long EOL'd.

I also don't subscribe to the position that it's irresponsible to claim support
for EOL'd products; by the same token, the reponsible thing would be to
include, by default, a middleware that sends warnings to users of old
browsers. We don't do that, because we're all consenting adults here.
And on that comparison, the old browser is arguably more of a risk than
the old database server -- the db, most likely, is not directly accessible
from the internet.

To address a specific suggestion:

On Saturday 14 June 2014 18:08:41 Marc Tamlyn wrote:
>
> That's not to say we should actively break support for old databases if
> they happen to work, but we should remove any conditional code we might
> have regarding them and we should not consider them when adding new
> features.

"remove any conditional code regarding them" is exactly what I'd call "actively
break support". What I want to do for "secondary support versions" is
- keep conditionals regarding them
- protect them from newer-version-only functionality (with no attempt to
add workarounds or client-side implementations)
- accept community patches to fix problems, as long as they don't put too
much of a burden on the code.

I'm +0 on dropping Oracle9 support completely at this point, which means,
like Marc suggests, we just forget about it in code and declare it unsupported
in docs. -0 on doing the same to Oracle 10. But it has to be a team decision,
either way.

Also note:

We claim to support MySql 5.0 and up.
http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf
(page no. 19, which is the 21st page of the PDF):
MySql 5.0 EOL'd in Dec 2011
MySql 5.1 in Dec 2013

We claim to support Postgres 8.4 and up -- 8.4 EOLs next month.

Our docs still speak about SQLite 3.3.5.

Besides database servers, there are also Python driver libraries to consider;
we claim to require cx_Oracle>=4.3.1, but with cx_Oracle, only the latest
version is really supported -- so we should require 5.1.3 (fixing the doc
to require 5.1.3 for Python3 was already on my to-do list). I suppose
similar issues exist with the other backends.

This discussion, as Aymeric noted, is really about all dependencies.
We discussed, and all but decided, to start using external dependencies
rather than vendoring libraries; but this means we can only do so for
libraries supported by projects with clear support policies. We need
to discuss the requirements for being a Django requirement.

Hope this isn't too messy to make sense,

Shai.

[Russell Keith-Magee]

Agreed. In times of old we also supported older versions of software because they were distributed by RHEL. However, we now have a security process that involves notification of RHEL staff (and others), and people pay for RHEL so that they get security updates for specific versions of software. 

By way of providing adequate notification that old versions are dropping off the list, introducing a system level warning if older versions of databases (or any dependency) are found would be a good idea IMHO.

Russ %-)

[Russell Keith-Magee]

On Sun, Jun 15, 2014 at 7:51 AM, Shai Berger <sh...@platonix.com> wrote:

Hi guys,

TL;DR -- ...sorry, there's no TL;DR here. It's a bunch of separate ideas. It's
a little lengthy. Please bear with me.

I'd like to compare our support for old database servers with our support
for old browsers. We only recently dropped code that supported IE 6/7 (!)
for a security (!) fix, and even that decision wasn't taken trivially. I don't
think suggestions that will break Django sites for IE8 users will be
appreciated, unless there is a great benefit on the other side. And IE8,
along with the OS which required it, are long EOL'd.

I also don't subscribe to the position that it's irresponsible to claim support
for EOL'd products; by the same token, the reponsible thing would be to
include, by default, a middleware that sends warnings to users of old
browsers. We don't do that, because we're all consenting adults here.
And on that comparison, the old browser is arguably more of a risk than
the old database server -- the db, most likely, is not directly accessible
from the internet.

There's another, more important difference, though. The database server is under the direct control of the developer. If I'm a developer, I'm actively choosing Django X, and I choose MyWonderDB 1.2.3. If I make a decision to upgrade to Django Y, the fact that my database is no longer supported is part of that decision - I either need to upgrade my database as well, or I need to evaluate whether "not supported" means "will actually break" or "might work, but we just aren't testing for it", and take the risk (and the related testing responsibility) onto my own project.

However, the website that I deploy is accessed by people whose software isn't under my control. People are still using IE6. Never mind that it's been EOLd; you'll pry their copy of Win95 out of their cold, dead hands. This long tail is essentially endless - as a web framework, when we drop support for a browser, we're talking about how much of this tail we're willing to cut off. IE8 may well be EOL, but Microsoft adoption rates and upgrade policies mean that there is still s substantial population using it, especially in non-technical and non-English speaking demographics.

 

To address a specific suggestion:

On Saturday 14 June 2014 18:08:41 Marc Tamlyn wrote:
>
> That's not to say we should actively break support for old databases if
> they happen to work, but we should remove any conditional code we might
> have regarding them and we should not consider them when adding new
> features.

"remove any conditional code regarding them" is exactly what I'd call "actively
break support". What I want to do for "secondary support versions" is
- keep conditionals regarding them
- protect them from newer-version-only functionality (with no attempt to
  add workarounds or client-side implementations)
- accept community patches to fix problems, as long as they don't put too
  much of a burden on the code.

I'm +0 on dropping Oracle9 support completely at this point, which means,
like Marc suggests, we just forget about it in code and declare it unsupported
in docs. -0 on doing the same to Oracle 10. But it has to be a team decision,
either way.

Agreed it's a team decision.

But this actually raises a middle ground suggestion. There's a difference between "We're no longer testing for version X", "we *believe* we *may* have broken support for version X" and "We *know* we've actually broken support for version X." Following on from my earlier suggestion about raising a system check warning if an old DB version is detected, we can use language that indicates the extent of the damage:

* if we're just taking a version out of our build pool, we say "version is no longer supported".

* if adding a new feature requires removing code that added specific support for an old version, we change the message to add "and we have reason to believe that version will behave unexpectedly."

The key here is that we don't just purge old version checks because we can; we only do so in the name of actual progress. I dont think we should purge a version check just because. However, we do have an obligation to adequately warn the user of problems we can foresee. 

 

Also note:

We claim to support MySql 5.0 and up.
http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf
(page no. 19, which is the 21st page of the PDF):
MySql 5.0 EOL'd in Dec 2011
MySql 5.1 in Dec 2013

We claim to support Postgres 8.4 and up -- 8.4 EOLs next month.

Our docs still speak about SQLite 3.3.5.

Besides database servers, there are also Python driver libraries to consider;
we claim to require cx_Oracle>=4.3.1, but with cx_Oracle, only the latest
version is really supported -- so we should require 5.1.3 (fixing the doc
to require 5.1.3 for Python3 was already on my to-do list). I suppose
similar issues exist with the other backends.

This discussion, as Aymeric noted, is really about all dependencies.
We discussed, and all but decided, to start using external dependencies
rather than vendoring libraries; but this means we can only do so for
libraries supported by projects with clear support policies. We need
to discuss the requirements for being a Django requirement.

Agreed. Any time we depend on an external source, we introduce the possibility of problems, and in an ideal world, we'd be testing for it. In practice, I don't think we can do that. The best we can hope to do is some basic coverage of versions, and documentation of specific versions we know to be a problem. This may mean documenting the specific versions that a release has been tested with, and the versions that we believe to be working.

Russ %-) 

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/201406150251.12616.shai%40platonix.com.

[Alex Gaynor]

On Sat, Jun 14, 2014 at 5:49 PM, Russell Keith-Magee <rus...@keith-magee.com> wrote:

On Sun, Jun 15, 2014 at 7:51 AM, Shai Berger <sh...@platonix.com> wrote:

Hi guys,

TL;DR -- ...sorry, there's no TL;DR here. It's a bunch of separate ideas. It's
a little lengthy. Please bear with me.

I'd like to compare our support for old database servers with our support
for old browsers. We only recently dropped code that supported IE 6/7 (!)
for a security (!) fix, and even that decision wasn't taken trivially. I don't
think suggestions that will break Django sites for IE8 users will be
appreciated, unless there is a great benefit on the other side. And IE8,
along with the OS which required it, are long EOL'd.

I also don't subscribe to the position that it's irresponsible to claim support
for EOL'd products; by the same token, the reponsible thing would be to
include, by default, a middleware that sends warnings to users of old
browsers. We don't do that, because we're all consenting adults here.
And on that comparison, the old browser is arguably more of a risk than
the old database server -- the db, most likely, is not directly accessible
from the internet.

There's another, more important difference, though. The database server is under the direct control of the developer. If I'm a developer, I'm actively choosing Django X, and I choose MyWonderDB 1.2.3. If I make a decision to upgrade to Django Y, the fact that my database is no longer supported is part of that decision - I either need to upgrade my database as well, or I need to evaluate whether "not supported" means "will actually break" or "might work, but we just aren't testing for it", and take the risk (and the related testing responsibility) onto my own project.

However, the website that I deploy is accessed by people whose software isn't under my control. People are still using IE6. Never mind that it's been EOLd; you'll pry their copy of Win95 out of their cold, dead hands. This long tail is essentially endless - as a web framework, when we drop support for a browser, we're talking about how much of this tail we're willing to cut off. IE8 may well be EOL, but Microsoft adoption rates and upgrade policies mean that there is still s substantial population using it, especially in non-technical and non-English speaking demographics.

 

I think an important consideration is "can a user work around it in their application", e.g. if we remove something from common middleware, they can add it into their own middleware easily enough, if we change the core HTTP processing pipeline, that's considerably more difficult for them, and such changes shouldn't be made lightly.

Alex

 

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq8497_tPwbnnft9hp0TB68UmXqqXFtnThtgidDFZhP%2BJc0A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

GPG Key fingerprint: 125F 5C67 DFE9 4084

[Michael Manfre]

I don't see how it should be up to Django to continue to support all of these archaic versions of Oracle. To paraphrase the mantra repeated during various mssql discussions, "Django doesn't need to include everything in core, it just needs to make it possible for others to implement". If people feel strongly about staying on a no longer supported version of Oracle, then they can either stick with an older version of Django or create django-decrepit-oracle.

Django should strip this legacy code.

Regards,

Michael Manfre

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFRnB2WU83xD9YXcqpS%3DNLHH2PdNRZFr3z5CJydxTxOa70eLHw%40mail.gmail.com.

[Hannu Krosing]

On 06/14/2014 02:40 PM, Tim Graham wrote:

It seems to weird to claim (even best-effort/community) support for a database that is no longer supported by its authors. Also, you can always use an older version of Django, right? I tend to think you're probably not interested in the latest and greatest Django if you're using a really old database. My general proposal (for all databases) would be to drop support for a database version in the Django release that follows its end-of-life date.

Regarding testing, Oracle is currently not on CI, but Shai and I are working to add support for 11 and 12. This would actually be the only database where we have testing for multiple versions. For the other databases we are using whatever version Ubuntu 12.04 ships with (PostgreSQL 9.1.13, MySQL 5.5.37).

Heh, The "whatever version Ubuntu 12.04 ships with" test policy seems kind of weird (especially if this is meant to go on forever :) )

According to http://www.postgresql.org/support/versioning/ PostgreSQL 9.1 was released 2.5 years ago and is in the middle of its 5 year life cycle which ends in September 2016.

PostgreSQL 9.1 also lacks lots of newer stuff.

Thanks to ubuntu/debian pg_createcluster  and friends it is actually easy to run multiple versions of postgresql (I have everything from 8.4 to latest 9.4 beta running in parallel on my laptop), so my suggestion would be at least for postgresql to

a) add pgdg repo to ubuntu ( http://www.postgresql.org/download/linux/ubuntu/ )
b) test with all versions supported by pgdg

Cheers
Hannu

--

You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/abfb2f24-ee06-4c0c-ab70-50530eb7fc83%40googlegroups.com.

[Ian Kelly]

On Sun, Jun 15, 2014 at 8:59 AM, Michael Manfre <mma...@gmail.com> wrote:
> I don't see how it should be up to Django to continue to support all of
> these archaic versions of Oracle. To paraphrase the mantra repeated during
> various mssql discussions, "Django doesn't need to include everything in
> core, it just needs to make it possible for others to implement". If people
> feel strongly about staying on a no longer supported version of Oracle, then
> they can either stick with an older version of Django or create
> django-decrepit-oracle.
>
> Django should strip this legacy code.

There's not a lot of that actually. Dropping 9i would let us get rid
of the regex version check:

https://github.com/django/django/blob/master/django/db/backends/oracle/base.py#L361
https://github.com/django/django/blob/master/django/db/backends/oracle/base.py#L648

and this one-line database ping workaround:

https://github.com/django/django/blob/master/django/db/backends/oracle/base.py#L715

and I'm not coming up with anything else.

Dropping 10g as well wouldn't definitely let us remove anything. It
might make it easy to fix #11580 for doing icontains queries on
TextFields, and it *might* let us get rid of the complicated
LIKE/LIKEC fallback from #14149. Both of these would need further
research and testing. Particularly in the LIKE/LIKEC case, as that
bug has a long and checkered past, with a history of failures on
*some* (apparently non-continuous) versions of Oracle 9 and *some*
versions of Oracle 10, and it may also be sensitive to database
configuration, which makes it hard to be sure whether it's finally
fixed in Oracle 11 or not.

Are there any other places where Oracle 9/10 may be holding back the
code base that I'm not aware of?

[Russell Keith-Magee]

On Sun, Jun 15, 2014 at 11:49 PM, Hannu Krosing <ha...@krosing.net> wrote:

On 06/14/2014 02:40 PM, Tim Graham wrote:

It seems to weird to claim (even best-effort/community) support for a database that is no longer supported by its authors. Also, you can always use an older version of Django, right? I tend to think you're probably not interested in the latest and greatest Django if you're using a really old database. My general proposal (for all databases) would be to drop support for a database version in the Django release that follows its end-of-life date.

Regarding testing, Oracle is currently not on CI, but Shai and I are working to add support for 11 and 12. This would actually be the only database where we have testing for multiple versions. For the other databases we are using whatever version Ubuntu 12.04 ships with (PostgreSQL 9.1.13, MySQL 5.5.37).

Heh, The "whatever version Ubuntu 12.04 ships with" test policy seems kind of weird (especially if this is meant to go on forever :) )

It's an arbitrary version selection of an old(ish) commonly used Linux distribution. 

In an ideal world: Yes, we'd test against every major distro, and every major Postgres version installed on that distro, and so on; but we have limited resources (including the patience to make and configure build boxes as one of those resources :-)

At some point in the future, long before EOL of Ubuntu 12.04, we'll probably upgrade the build boxes to 14.04. I'm guessing the introduction of Marc's PostgreSQL-specific features from his Kickstarter might be the stimulus for this.

 

According to http://www.postgresql.org/support/versioning/ PostgreSQL 9.1 was released 2.5 years ago and is in the middle of its 5 year life cycle which ends in September 2016.

PostgreSQL 9.1 also lacks lots of newer stuff.

Thanks to ubuntu/debian pg_createcluster  and friends it is actually easy to run multiple versions of postgresql (I have everything from 8.4 to latest 9.4 beta running in parallel on my laptop), so my suggestion would be at least for postgresql to

a) add pgdg repo to ubuntu ( http://www.postgresql.org/download/linux/ubuntu/ )
b) test with all versions supported by pgdg

Yes, this is possible; the question is whether this is a valuable use of our limited resources. I can only think of a handful of occasions in Django's 8 year public history where SQL-handling behaviour in PostgreSQL has changed in a way that required testing multiple versions - and most of those occasions were in the 7.X-8.X transition. Django's usage of SQL is fairly conservative; the areas where PostgreSQL is add features aren't the areas where Django treads, generally. As a result, there is a reduced imperative to test all these versions.

This will of course change when we start supporting PostgreSQL-specific features, so we'll probably have to revisit this - but even then, I suspect testing an old version (e.g., 9.1) and a recent version (e.g., 9.4) will probably give us sufficient confidence that the build is working.

Yours,

Russ Magee %-)

 

[Shai Berger]

On Sunday 15 June 2014 10:59:17 Michael Manfre wrote:
> I don't see how it should be up to Django to continue to support all of
> these archaic versions of Oracle. To paraphrase the mantra repeated during
> various mssql discussions, "Django doesn't need to include everything in
> core, it just needs to make it possible for others to implement". If people
> feel strongly about staying on a no longer supported version of Oracle,
> then they can either stick with an older version of Django or create
> django-decrepit-oracle.
>
> Django should strip this legacy code.
>

I find this argument rather convincing. It blends well with several ideas I
have floating around, of making the Oracle backend (and where applicable,
others, of course) more easily extandable.

That said -- the Oracle backend is currently not extension-friendly enough for
my tastes, and I don't think it is a good idea to make the changes I have in
mind for 1.7; I haven't looked at other backends enough to make more general
comments. And I'd really like to postpone any stripping-out of support until
others can, indeed, implement it easily.

I also think we should, indeed, change the "advertising", already with 1.7, to
say that support for Oracle < 11.2 is deprecated; after we've made it easy
enough to extend, we can adopt Tim's rule of "dropped once EOL'd".

On Sunday 15 June 2014 12:34:04 Ian Kelly wrote, and I paraphrase: "there's
not so much to win by dropping oracle 9/10". Perhaps this is true the
currently-implemented feature-set, but I, for one, suspect we could make use
of recursive CTEs (Oracle 11.2, PG9, Sql Server 2008 IIRC) and other new
database features.

So, to summarize: I am +1 on changing docs to encourage users to use supported
database servers; I am still +0,-0 on dropping the current Oracle 9,10
(respectively) support in the code for 1.7; and +1 on dropping it in 1.8 after
making it easy to support outside core.

Shai.

[Marc Tamlyn]

There will be a need for some gradiented support of Psql with contrib.postgres. I think a sensible CI setup would be to run the full test suite against 9.4 and the contrib.postgres test suite only against 9.1-9.3. That would be my preferred compromise.

Marc

--

You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq849rV6pu_gX9JaCKOHxj%2BFU9p9U3ii%2BA54VHjF7WncT5Gw%40mail.gmail.com.

[Reinout van Rees]

On 14-06-14 02:52, Tim Graham wrote:
> 11.1 - Aug 2007 - Aug 2012 - Aug 2015
> 10.2 - Jul 2005 - Jul 2010 - Jul 2013

To provide an additional data point: I checked with a colleague. We do a
lot of business with governmental organizations in the Netherlands
(mainly water boards). Most of them are on 11. With one or two still
migrating from 10... :-)


Reinout

--
Reinout van Rees http://reinout.vanrees.org/
rei...@vanrees.org http://www.nelen-schuurmans.nl/
"Learning history by destroying artifacts is a time-honored atrocity"

[Vladimir U.]

суббота, 14 июня 2014 г., 4:52:57 UTC+4 пользователь Tim Graham написал:

+1 for drop <11 ver.
It would be nice if newer Django versions work perfect with Oracle ver > 11 than "not all features work" with all Oracle DB versions.