Note, there is certainly interest in having jOOQ-provided schema versioning capabilities, i.e. a way to indicate that:
- A table - A column - A procedure - Etc. Are available only in a set of versions and then run the jOOQ runtime with a version configuration, which influences all the SELECT * style features. The relevant feature request is here: https://github.com/jOOQ/jOOQ/issues/4232 It is far from being well-defined, though. 2018-03-19 9:32 GMT+01:00 Lukas Eder <[email protected]>: > Hi Samir, > > 2018-03-19 1:18 GMT+01:00 Samir Faci <[email protected]>: > >> 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. >> > > And you get free performance benefits from it, including but not limited > to: > > - Less data transfer > - Less locking > - Higher chance of applying covering indexes > - More join elimination (depending on your database) > > So, generally a good appraoch > > >> 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. >> > > Of course, you're aware that even if this "exploding" didn't happen, you'd > still run into problems afterwards, when trying to access the column from > the result. > > >> 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? >> > > You probably mean UpdatableRecords. They're safe *if* you set updated > column names individually, e.g. > > record.setA(a); > record.setB(b); > record.store(); > > > If, however, you use e.g. the generated POJOs and then load them into a > record, then you'll run into the same problem on insert / update: > > record.from(pojo); // Will set all the known column values > record.store(); > > > There might be other API as well. > > Are there any other API calls that should be avoided? >> > > Probably, e.g. every time you access Table.fields() - or when that is > being accessed internally. Should be rare, though. > > >> would aggregation methods be affected by this? .selectCount() ? >> > > Not per se. > > >> 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 not sure about the difficulty here. The schema version and your client > logic version should " simply match". What is a use-case where they don't > match? > > >> 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. >> > > I'm assuming you are working on feature branches for these things, are you? > -- 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.
