Thanks for filing the issues!
In this case, I prefer to avoid fetching each column individually as it is
much more verbose than selectFrom.
In the short term, I’m working around this by generating code for the old
and new schema with runtime table mapping and introducing my own Hybrid
data POJOs implementing both record interfaces. The hybrid POJOs simply
don't get the column set in the old schema, but the generated from method
populates it in the new schema.
/**
* A hybrid foo record bridging schema version 1 to 2
*/
public class HybridFoo extends Foo3Record
implements IFoo, IFoo3, HybridFoo {
@Override public void from(IFoo from) {
setBar(from.getBar());
setBaz(from.getBaz());
}
@Override public <E extends IFoo> E into(E into) {
into.from(this);
return into;
}
public static List<HybridFoo> fromResults(Result<Foo> results) {
return results.stream().map(r -> {
HybridFoo merged = new HybridFoo();
merged.from((IFoo) r);
return merged;
}).collect(Collectors.toList());
}
public static List<HybridFoo> fromResults2(Result<Foo2> results) {
return results.stream().map(r -> {
HybridFoo merged = new HybridFoo();
merged.from((IFoo2) r);
return merged;
}).collect(Collectors.toList());
}
}
On Wednesday, March 15, 2017 at 5:55:47 PM UTC-4, Lukas Eder wrote:
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] <javascript:>>:
>
>> 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] <javascript:>.
>> 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.
