Starts to use the datasource storage collection to store configs moving
forward. WIP
---------
Co-authored-by: Manish Kumar <107841575+sondermanish@users.noreply.github.com>
## Description
- Remove Oracle integration feature flag.
- Remove `Optional` qualifier from the SSL header on the datasource
config page.
Fixes#20797
## How Has This Been Tested?
- Manual
### Test Plan
> Add Testsmith test cases links that relate to this PR
### Issues raised during DP testing
> Link issues raised during DP testing for better visiblity and tracking
(copy link from comments dropped on this PR)
## Checklist:
### Dev activity
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] PR is being merged under a feature flag
### QA activity:
- [ ] Test plan has been approved by relevant developers
- [ ] Test plan has been peer reviewed by QA
- [ ] Cypress test cases have been added and approved by either SDET or
manual QA
- [ ] Organized project review call with relevant stakeholders after
Round 1/2 of QA
- [ ] Added Test Plan Approved label after reveiwing all Cypress test
## Description
- Update the Oracle plugin code to use newer error framework infra.
- Add support to fetch DB schema and show dynamic query templates.
- The following info is shown to the users as part of the DB schema:
table names, column names for each table, column types, primary key,
foreign key
- Update static query templates.
- Update datasource form to show mandatory fields with asterik mark
- Update datasource validity check to return error on empty password
field
- Improve data read for the following types: `timestamp with local time
zone` , `clob`, `nclob`
- Minor refactor into modular re-usable functions
Fixes#20794#20795
## Type of change
- New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- Manual
- JUnit TC to be added via separate PR. Another issue it open to track
it.
### Test Plan
[Test plan
links](https://github.com/appsmithorg/TestSmith/issues?q=is%3Aopen+is%3Aissue+label%3A%22Oracle+SQL+DB%22)
### Issues raised during DP testing
https://github.com/appsmithorg/appsmith/issues/21487
## Checklist:
### Dev activity
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [x] PR is being merged under a feature flag
### QA activity:
- [ ] Test plan has been approved by relevant developers
- [x] Test plan has been peer-reviewed by QA
- [ ] Organized project review call with relevant stakeholders after
Round 1/2 of QA
- [ ] Cypress test cases have been added and approved by either SDET or
manual QA
- [ ] Added Test Plan Approved label after reviewing all Cypress tests
- [ ] Added Test Plan Approved label after developers review JUnit tests
## Description
- This PR introduces support for prepared statements to the Oracle
integration that is currently behind a feature flag.
- Fixed a bug with PL/SQL cmd due to semicolon.
- Fixed a bug with reading Array type.
- The following tasks will be taken up separately and will not be part
of this PR. They will be resolved before lifting the feature flag:
- DB structure and query templates
- Error messages infra
- JUnit TC
- The following data types were tested: `char, varchar, array, int,
float, double, raw, timestamp, timestamp_tz, interval` . The following
cmd was used to test the feature:
```
select * from TYPESTEST4 where c_varchar2={{'varchar2'}}
and c_nvarchar2={{'nvarchar2'}}
and c_number={{1}}
and c_float={{11.22}}
and c_date={{'2002-10-03'}}
and c_binary_float={{11.22}}
and c_binary_double={{11.22}}
and c_timestamp=TO_TIMESTAMP({{'01-01-1997 09:26:50.124'}})
and c_timestamp_tz=TO_UTC_TIMESTAMP_TZ({{"1997-01-01T09:26:56.66+02:00"}})
and c_interval_day=NUMTODSINTERVAL({{1}}, {{'HOUR'}})
and c_char={{'char '}}
and c_raw=utl_raw.cast_to_raw({{'raw'}})
```
- `JSON` type could not be tested because it was only recently
introduced in version 21c. However, the Oracle test instance credentials
available on Notion are for 19c. Tracking it
[here](https://github.com/appsmithorg/appsmith/issues/20796).
Fixes#20533
## Type of change
- New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- Manual
## How to Test
```
(1) Create a Table with various data types like:
create table typestest4 (
c_varchar2 varchar2(20),
c_nvarchar2 nvarchar2(20),
c_number number,
c_float float,
c_date date,
c_binary_float binary_float,
c_binary_double binary_double,
c_timestamp timestamp,
c_timestamp_tz timestamp with time zone,
c_timestamp_ltz timestamp with local time zone,
c_interval_year interval year to month,
c_interval_day interval day to second,
c_raw raw(256),
c_rowid rowid,
c_urowid urowid,
c_char char(256),
c_nchar nchar(256),
c_clob clob,
c_nclob nclob,
c_blob blob
)
(2) Insert data into the table:
insert into TYPESTEST4 values (
'varchar2',
'nvarchar2',
1,
11.22,
'03-OCT-02',
11.22,
11.22,
TIMESTAMP'1997-01-01 09:26:50.124',
TIMESTAMP'1997-01-01 09:26:56.66 +02:00',
TIMESTAMP'1999-04-05 8:00:00 US/Pacific',
INTERVAL '1' YEAR(3),
INTERVAL '1' HOUR,
utl_raw.cast_to_raw('raw'),
'000001F8.0001.0006',
'000001F8.0001.0006',
'char',
'nchar',
'clob',
'nclob',
utl_raw.cast_to_raw('raw')
)
(3) Run the following select cmd with prepared statement toggle on:
select * from TYPESTEST4 where c_varchar2={{'varchar2'}}
and c_nvarchar2={{'nvarchar2'}}
and c_number={{1}}
and c_float={{11.22}}
and c_date={{'2002-10-03'}}
and c_binary_float={{11.22}}
and c_binary_double={{11.22}}
and c_timestamp=TO_TIMESTAMP({{'01-01-1997 09:26:50.124'}})
and c_timestamp_tz=TO_UTC_TIMESTAMP_TZ({{"1997-01-01T09:26:56.66+02:00"}})
and c_interval_day=NUMTODSINTERVAL({{1}}, {{'HOUR'}})
and c_char={{'char '}}
and c_raw=utl_raw.cast_to_raw({{'raw'}})
```
### Test Plan
> Add Testsmith test cases links that relate to this PR
### Issues raised during DP testing
> Link issues raised during DP testing for better visiblity and tracking
(copy link from comments dropped on this PR)
## Checklist:
### Dev activity
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] PR is being merged under a feature flag
### QA activity:
- [ ] Test plan has been approved by relevant developers
- [ ] Test plan has been peer reviewed by QA
- [ ] Cypress test cases have been added and approved by either SDET or
manual QA
- [ ] Organized project review call with relevant stakeholders after
Round 1/2 of QA
- [ ] Added Test Plan Approved label after reveiwing all Cypress test
Solves a single thing in the build configurations, resulting in a few
wins.
1. Reduced number of warnings in the output.
1. In release branch:
```
mvn clean package -DskipTests | grep --fixed-strings --count '[WARNING]'
3233
```
1. In this PR's branch:
```
mvn clean package -DskipTests | grep --fixed-strings --count '[WARNING]'
172
```
2. All uber-jar files are shaded twice, currently. Once with the default
execution of `maven-shade-plugin`, and again with the `shade-plugin-jar`
execution in these `pom.xml` files. This is double-work, and is the
cause of most of the warnings we see.
1. This `shade-plugin-jar` was added to have the plugin information
included in the `/META-INF/MANIFEST.MF` file, since we can't configure
the default execution of the shade plugin (it comes to us from Spring
Boot).
2. Instead, we switch to configuring plugin information in a
`/plugin.properties` file.
3. Previously, we used `/plugin.properities` for plugin information in
dev time, and `/META-INF/MANIFEST.MF` in production. This PR will change
it so that we use `/plugin.properties` all the time. We configure PF4J
with a custom plugin manager to achieve this.
3. Moved all `plugin.properties` into `src/main/resources`, so that they
land up in the root of the final jar files. But this means, during
development, loading the plugin fails since it looks for a
`plugin.properties` at the root of the plugin module, i.e., next to the
`src` folder.
1. For this, in the custom plugin manager class, we change where we look
for the `plugin.properties` file during development mode. In this mode,
we look at the `target/classes/plugin.properties` file, which is where
maven saves this file, taken from
`src/main/resources/plugin.properties`.
2. This also solves the duplication of the plugin properties that's
currently present, between `plugin.properties` and the `<properties>`
section of `pom.xml` files.
Here's the shade plugin's default execution and configuration, from
Spring Boot:
https://github.com/spring-projects/spring-boot/blob/v3.0.1/spring-boot-project/spring-boot-starters/spring-boot-starter-parent/build.gradle#L174.
