Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#301 Make SQL generators extensible so that custom generators could be plugged in without Pramen recompilation #352

Merged
merged 5 commits into from
Feb 12, 2024

Conversation

yruslan
Copy link
Collaborator

@yruslan yruslan commented Feb 6, 2024

Closes #301

The PR adds the ability to use custom JDBC drivers with custom SQL generators without recompiling Pramen. You can also use custom SQL generators with JDBC drivers that are already supported by Pramen, if there is a reason to do that.

Example JDBC reader config:

sources = [
  {
    name = "jdbc"
    factory.class = "za.co.absa.pramen.core.source.JdbcSource"

    jdbc {
      driver = "com.example.Jdbc.Driver"
      connection.string = "$url"
      user = "$user"
      password = "$password"
    }

    has.information.date.column = true
   
    information.date.column = "INFO_DATE"
    information.date.type = "date"
    information.date.app.format = "YYYY-MM-dd"

    # Specify the custom generator for the custom JDBC driver
    sql.generator.class = "com.example.CustomSqlGeneratorClass"
  }
]

Copy link

github-actions bot commented Feb 6, 2024

Unit Test Coverage

File Coverage [94.92%] 🍏
TableReaderJdbcConfig.scala 100% 🍏
CsvUtils.scala 100% 🍏
SqlGeneratorHive.scala 96.97% 🍏
SqlGeneratorOracle.scala 96.94% 🍏
SqlGeneratorPostgreSQL.scala 96.84% 🍏
SqlGeneratorDb2.scala 96.84% 🍏
SqlGeneratorGeneric.scala 96.84% 🍏
SqlGeneratorHsqlDb.scala 96.84% 🍏
SqlGeneratorDenodo.scala 96.78% 🍏
SqlGeneratorMicrosoft.scala 95.53% 🍏
SqlGeneratorSas.scala 94.08% 🍏
SqlGeneratorLoader.scala 92.49% 🍏
TableReaderJdbc.scala 87.91% 🍏
Total Project Coverage 83.48% 🍏

@yruslan yruslan marked this pull request as ready for review February 6, 2024 13:13
class SqlGeneratorDummy(sqlConfig: SqlConfig) extends SqlGenerator {
def getSqlConfig: SqlConfig = sqlConfig

override def getDtable(sql: String): String = null
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may consider using ??? instead of null to avoid the usage of nulls in Scala.

Copy link
Collaborator Author

@yruslan yruslan Feb 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting idea. I always use null in dummy classes, coming from Uncle Bob mocking principles. And I use ??? when something not implemented yet, but I need the project to compile.

The difference for me is:

  • When ??? is returned it means the method implementation is unfinished, and no ??? should be in PRs.
  • When null is returned it means it is a dummy class and the implementation of this method is never intended.

Let me know if given this, you still prefer ???.


def fromDriverName(driver: String, sqlConfig: SqlConfig, extraConfig: Config): SqlGenerator = {
val sqlGenerator = driver match {
def fromDriverName(driver: String, sqlConfig: SqlConfig): SqlGenerator = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you leave the methods fromDriverName and fromClass with public access on purpose?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, it indeed makes sense to make the private since the object has getSqlGenerator() method that can be used in both cases.

@yruslan yruslan merged commit 35d056a into main Feb 12, 2024
9 checks passed
@yruslan yruslan deleted the feature/301-extensible-sql-generators branch February 12, 2024 13:34
@yruslan yruslan mentioned this pull request Feb 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make SQL dialects extensible with the ability to load dynamically
2 participants