Refactor DDL generation and DDL run into separate plugins

[rPraml]

Hello @rbygrave I see that you do a lot of refactoring and want to share some ideas

I would suggest to extract DDL generation and run into a ServerPlugin

I've done that already here FOCONIS@699f7a8

I also have extracted the DbMigrationRunner into a separate plugin

FOCONIS@208e987

And DbMigration is fully configurable from properties

FOCONIS@9d1f419

If you find them useful, I can create a PR

[rbygrave]

extract DDL generation and run into a ServerPlugin

The issue with this is the relative ordering of DDL generation and run versus other plugins. That is, the ddl generation and run MUST happen before other plugins and that change doesn't do that. This effectively changes the ordering such that ddl might not get done first.

extracted the DbMigrationRunner into a separate plugin

I don't yet see the value there? Maybe I need to look again later.

DbMigration is fully configurable from properties

Yes, looks like useful improvements.

[rbygrave]

you do a lot of refactoring

With respect to refactoring that is along the lines of "extracting a module" ... in my head I see it there is a balance with the view that "less modules is simpler". That means, with Ebean we should tend to just keeping everything together unless we get benefits like:

• Something is truely optional at runtime
• Something is easier to maintain going forward as a separate thing (typically due to dependencies)

For example, on one hand it's simpler to keep all the "platforms" in ebean-api as they are currently. On the other hand "at runtime" 99% of apps will be only using a single platform (e.g. Postgres) and hence they have a decent amount of code that they don't need at all (approx 100kb in jar terms).

So the argument is approximately - Is a 100kb saving of unused code at runtime worth it versus the relative pain of having all these separate platforms (ebean-postgres, ebean-mysql etc)?

For another example, noting that ebean-ddl-generator is not expected to be a runtime dependency (test dependency only), we actually don't care how big it gets and happily leave all the platform ddl generation code in there together. There is no motivation for pulling out things that are test scope only dependencies.

---

There are 2 more things that I have interest in pulling out as separate modules

• The joda time scalar types (so can be an optional dependency only required by apps using joda time
• The Jackson JsonNode scalar types (can then be an optional dependency only required by apps using Jackson JsonNode)

The additional benefit from pulling out those as separate modules is that it tests out / exercises Ebeans API (SPI really) around support for registering support for custom types, much like ebean-postgis supports the Postgres GIS types. So there is longer term benefit from getting that SPI right (well, more right that it is today).

---

Is 100Kb really that significant? It's probably marginal. I'm the type of person who is aware that the ebean-core jar has just tipped over 2Mb [and also aware in comparison terms that hibernate-core (latest version 6 rc) is tipping over 9Mb !!! jackson-databind is 1.5Mb, jackson-core is 370Kb, antlr4-runtime is 340Kb].

Anway, that is a bit of a brain dump.

[rbygrave]

the relative ordering of DDL generation and run versus other plugins

If this question of plugin execution order isn't actually an issue in practice (e.g. no one actually writes plugins) ... then pulling those out as plugins is quite elegant. Hmmm.

[rbygrave]

I'm going to try the "transfer to discussion" on this issue.