I'm sorry about the delay. Your e-mail got filtered by both google groups' as well as my gmail's spam filters... I wonder, why
2013/9/30 <[email protected]> > I'm writing some code to generically generate Select objects according to > an internal modelling standard. > > Assuming the following code: > > Table<?> aliasedTable = table.as("ab12"); > List<?> keys = aliasedTable.getKeys(); > *for *(Object o : keys) { > UniqueKey uk = (UniqueKey)o; > *for *(Object keyField : uk.getFields()) { > TableField<?, ?> field = (TableField) keyField; > //the above field reference is not properly aliased > //to use the above field I must do this: > Field<?> useThisField = aliasedTable.field(field.getName()); > } > } > > Is this intentional? Defect to be fixed? I would have assumed the field > would be aliased. > That is "intentional". Foreign key constraints are generally independent of concrete table aliasing. In particular, the following example shows that it wouldn't make sense to apply aliasing to foreign key constraint navigation: // This is a UniqueKey aliasedTable.getKeys().get(0) // This is a ForeignKey referencing the above UniqueKey .getReferences().get(0) // This is a Table X hosting the Foreign Key .getTable() // This is the same ForeignKey again .getReferences().get(0) // This is the same UniqueKey again .getKey() // This is a Field, which would still have to be aliased .getFields().get(0) Agreed, that's not a very concise rationale, but maybe you see what I'm trying to hint at :-) Cheers Lukas -- 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/groups/opt_out.
