Should there still be conditional statements to do with 'execute immediate' and the more recent versions of the database? Everyone should have been upgrading to more recent versions by now. I'm quite happy to do these changes if the general consensus is that they are no longer needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oracle 8i extended support ended in 2006. It's quite reasonable to stop support of Oracle 8i also in utPLSQL.
Advantage for me: a little easier to make changes without all this conditional statements.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know from experience that just because something is no longer supported by the vendor doesn't mean that it isn't being used in business critical production environments (including Oracle databases!)
Apart from tidying up the code, would dropping support for old versions of Oracle actually add anything to the project? Is this legacy code preventing any new features or holding us back?
On the one hand, I don't really think that removing it just for the sake of tidying up the code is a strong enough reason. I must admit, I quite like the idea that it will work on pretty much any version of Oracle.
On the other hand, you're right that Oracle 8 is pretty old now and there's no point dragging along legacy code just for the sake of it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One more thing.
Who will test new features on Oracle 8i? If somebody will, it means, that adding features will take additional time making it harder. If no one will - Oracle 8i support in utPLSQL doesn't really exist.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We should be careful not to overstate the level of support we can offer (and amount of testing that is done) for any version...
This project (like many open source projects) is run on a "best endeavours" basis by an absolute minimum of individuals doing it as a hobby in their spare time. We develop, test and support as well as we can, but we can't make any guarantees or promises about what will or will not work on any given environment.
utPLSQL is currently at major version 2. In this version, it has handled code for different Oracle versions by commenting out blocks of code during the install. Oracle 10g Release 2 introduced "conditional compilation". I haven't used it, but it does look to be more elegant than our current mechanism and seems to be the official way of achieving this requirement.
We could start work on major version 3 - replacing the current versioning mechanism with "conditional compilation". That would mean that the minimum requirement for version 3 would be 10g Release 2 (though I understand patch sets were released for 10g from 10.1.0.4 onwards and for 9i from 9.2.0.6 onwards). We could also take this opportunity to consider any other breaking changes worthy of a major release. We should still offer the latest version 2 release for anyone wanting to use it on an older database and try to fix any bugs as reported, but we can be selective about adding new features.
Should there still be conditional statements to do with 'execute immediate' and the more recent versions of the database? Everyone should have been upgrading to more recent versions by now. I'm quite happy to do these changes if the general consensus is that they are no longer needed.
Oracle 8i extended support ended in 2006. It's quite reasonable to stop support of Oracle 8i also in utPLSQL.
Advantage for me: a little easier to make changes without all this conditional statements.
I know from experience that just because something is no longer supported by the vendor doesn't mean that it isn't being used in business critical production environments (including Oracle databases!)
Apart from tidying up the code, would dropping support for old versions of Oracle actually add anything to the project? Is this legacy code preventing any new features or holding us back?
On the one hand, I don't really think that removing it just for the sake of tidying up the code is a strong enough reason. I must admit, I quite like the idea that it will work on pretty much any version of Oracle.
On the other hand, you're right that Oracle 8 is pretty old now and there's no point dragging along legacy code just for the sake of it.
One more thing.
Who will test new features on Oracle 8i? If somebody will, it means, that adding features will take additional time making it harder. If no one will - Oracle 8i support in utPLSQL doesn't really exist.
Exactly my reasoning as well. It makes the code look a bit laboured in places as well. If it can't be / or won't be tested what's the point anyway.
We should be careful not to overstate the level of support we can offer (and amount of testing that is done) for any version...
This project (like many open source projects) is run on a "best endeavours" basis by an absolute minimum of individuals doing it as a hobby in their spare time. We develop, test and support as well as we can, but we can't make any guarantees or promises about what will or will not work on any given environment.
utPLSQL is currently at major version 2. In this version, it has handled code for different Oracle versions by commenting out blocks of code during the install. Oracle 10g Release 2 introduced "conditional compilation". I haven't used it, but it does look to be more elegant than our current mechanism and seems to be the official way of achieving this requirement.
We could start work on major version 3 - replacing the current versioning mechanism with "conditional compilation". That would mean that the minimum requirement for version 3 would be 10g Release 2 (though I understand patch sets were released for 10g from 10.1.0.4 onwards and for 9i from 9.2.0.6 onwards). We could also take this opportunity to consider any other breaking changes worthy of a major release. We should still offer the latest version 2 release for anyone wanting to use it on an older database and try to fix any bugs as reported, but we can be selective about adding new features.
I've started a separate thread to discuss potential features for the next major version: [bbffe5b0]
Related
Discussion - Archive: bbffe5b0