Commit Graph

5 Commits

Author SHA1 Message Date
Nidhi
2c7798cca6
chore: Refactoring datasource storage consumption to start using the new collection (#23296)
Starts to use the datasource storage collection to store configs moving
forward. WIP

---------

Co-authored-by: Manish Kumar <107841575+sondermanish@users.noreply.github.com>
2023-05-23 19:27:53 +05:30
Sumit Kumar
09fd519e2c
chore: Oracle: add JUnit TCs (#22788)
## Description
- Add JUnit TCs
- Minor improvement to reading of data types: `timestamp`, `raw`, `blob`

Fixes #20535
2023-05-01 21:32:02 +05:30
Sumit Kumar
0e54c57ead
feat: Oracle integration: Add support for DB schema and update error infra (#22634)
## 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
2023-04-28 17:43:54 +05:30
Shrikant Sharat Kandula
4280ded88e
chore: Fix unnecessary re-shading of jars (#21994)
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.
2023-04-03 17:49:21 +05:30
Sumit Kumar
e3c8ca2d5c
feature: Introduce Oracle Integration behind feature flag (#21273)
- Introduce Oracle Integration behind feature flag.
2023-03-16 16:54:25 +05:30