Thank you very much for your suggestion. Incidentally, I've just registered two related feature requests recently:
Functional aliasing of columns after selecting them: https://github.com/jOOQ/jOOQ/issues/5952 Supporting "invisible" columns: https://github.com/jOOQ/jOOQ/issues/5969 Your feature request fits well into this potential new set of features, where a SELECT field list can be filtered after having been declared. For example (hypothetical syntax) ctx.select() .filter(f -> !f.getName().equals("NEW_FIELD_AFTER_MIGRATION") .from(TABLE) ... .fetchInto(TABLE); // Retain the TableRecord result type There's a number of features that would be useful to be included in a similar fashion. Of course, we'll always have to be careful here. The price to pay for "synthetic" SQL clauses is relatively high, as these clauses compromise jOOQ's philosophy of being a straightforward SQL dialect abstraction. I.e. such a filter() clause has no corresponding SQL clause, and would be a pure jOOQ expression tree transformation feature. Then again, the quick win here for you would be to explicitly select fields (as you often should), by writing: ctx.select(Stream.of(TABLE.fields()).filter(...)) .from(TABLE) ... .fetchInto(TABLE); There are other interesting questions. What happens if columns are renamed? Split? Moved to other tables? 2017-03-14 1:19 GMT+01:00 'Chris Conroy' via jOOQ User Group < [email protected]>: > I would like to optionally exclude a column from being added to selectFrom > (and similar) queries based on some runtime information. I don’t see a way > to do this, but perhaps I am just not seeing a configuration option? > > In general, it seems like this would be a useful feature for supporting > incremental, additive changes to data models. So, if this isn’t currently > supported, what are your thoughts on adding this as a feature? > > Some more context: > > I maintain a component that has some database tables backing it, and it is > used by many different applications. I created a row in the database schema > to define the “library schema” version to support eventual modification of > the data model that would let me support multiple versions of the backing > datastore with one version of the library code. > > I would like to add a column to these database tables which I would only > try to write/read if the library schema version has been incremented. > > However, I have many usages of selectFrom. If I add this new field to the > jOOQ generated code, then all selectFrom queries on affected tables fail > for users that haven’t migrated because that field doesn’t exist. So, I’d > like to blacklist this field based on the value of the library schema > version. > > > -- > 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. > -- 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.
