So a little background.
We maintain a git repo where we check in all the sql changes that are in slated to go to production. We apply all the SQL deltas to the current prod schema and generate the jooq library based on base schema + deltas and publish it as a maven artifact. It's essentially an in house version of flyway + Jooq generation on top of it. The issue we keep on running into is that we've had a few production issues sneak in when a SQL we generated has references to columns that haven't made it out to production. We try to avoid using things like selectFrom() and basically any form of select * and instead explicitly list the columns being requested in order to ensure that this doesn't happen. This is is an issue because Jooq has a tendency to explode a * into all the fields it knows about which causes issues when the column requested is undefined. What I'm looking for is if: 1. There were any other anti-patterns to avoid these gotchas from happening, currently both dsl.selectFrom() and dsl.select().from(tableName) are patterns we avoid. Are records safe to use? Are there any other API calls that should be avoided? would aggregation methods be affected by this? .selectCount() ? 2. IF there is a better pattern for packaging / releasing artifacts. I suppose we could explicitly mention which SQL deltas to apply when generating a maven release but that seems difficult to maintain. I'm mainly trying to determine which patterns to avoid and if we can improve our workflow to completely avoid a dev checkin inadvertently breaking things. There shouldn't be a need to prevent a developer from checking in a sql that will is in development, but at the same time we don't want something in DEV to be breaking things because another developer is ready to ship his / her feature and accidentally pulled some code on a completely different code path that suddenly breaks because of that. Any thoughts / suggestions? -- Samir Faci -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
