First aproach to new driver... reusing code...

[josejuanmontiel]

The idea... include new driver reusing actual code... for later dinamically load by configuration.

With the two (three) actual driver ... use ifs inside actual backend... because new one of new drivers change the code more drastically, decide to implements new backend.

And to reuse actual code in backend that don't change... in this backend include the "parent" of sql backend (the actual one) and only reimplement those methods that didn't change.

The trick its done here

type csvqDBWriter struct { sqlDBWriter }

reusing the actual implementation ... and only change the method ... that realy change...

[knadh]

Hi @josejuanmontiel. Thanks for the inline comments on the PR, but could you please explain here in a few bullet points, what exactly is changing, why, and how it helps. The overall architecture.

[josejuanmontiel]

Hi!

• What exactly is changing? There is an interface for the backends (before now, only one) the change consider this backend as parent backend to others, that only need to override the methods they change for new functionaly of this "driver"...

• why? Splitting the new functionality to connect new database in different backend, organize the code better to future loading dinamically.

• and how it helps? It could lead to remove the "if postgres" in some places ... if split the sql backend in two .. for mysql and postgres.

• The overall architecture. To reuse the code in other backend need a few minor changes

  1. CreateTableSchema goes public to be called from jobber.go before w.RegisterColTypes(cols, colTypes)
  2. Move to the interfaces some types to organize
  3. Now types sqlDB and sqlDBWriter aggrete the fields, that leads to remove the name attribute backend *sqlDB from sqlDBWriter
  4. CreateTableSchema have the lock inside (not ouside)
  5. The new backend (csv) only implements the methods that have "sql code" that change in this database.

As bonus, need some extra configuration too... i include the comented option to run the jobber_test.go with testcontainer.

TODO:

1. Adding some free CI ¿circleci?
2. "Parametrizing" the it test with test container (adding // +build integration)
3. Adding some test for the new csvq driver

[knadh]

Thanks for the update. Will try to review this some time soon.

[knadh]

Please see this https://github.com/knadh/sql-jobber/pull/23#issuecomment-1730871141