Unfortunately the tables are not the same, though sometimes they have the same name but less columns.
The data is really transformed, not just copied - though in some rare occasions this might also be the case. It's ok, that each Tables class is named Tables, but if it wouldn't be final with a public constructor, it this could be done manually, which I think is ok. Am Dienstag, 5. März 2013 23:38:44 UTC+1 schrieb Lukas Eder: > > Hmm, unfortunately, the Tables.java file cannot be renamed through the > GeneratorStrategy. This should be fixed in the next release: > https://github.com/jOOQ/jOOQ/issues/2307 > > I'll also review the usage of the "final" keyword (and private > constructors) in some of the generated artefacts: > https://github.com/jOOQ/jOOQ/issues/2308 > > I assume that your tables have the same name in both DB1 and DB2? > Otherwise, static imports or explicit imports might do the trick: > > import static at.ditech.shop.artikel.db1.Tables.*; > import static at.ditech.shop.artikel.db2.Tables.*; > > or > > import at.ditech.shop.artikel.db1.tables.DB1TableX; > import at.ditech.shop.artikel.db2.tables.DB2TableX; > > > 2013/3/5 Matthias Fuchs <[email protected] <javascript:>> > >> ok, that is at least one step closer to an optimal solution. Thanks. >> >> But still, why is the Tables class final? It would be so much more easy >> to create your own wrapper class, if this wouldn't be the case. >> >> >> Am Dienstag, 5. März 2013 20:08:17 UTC+1 schrieb Peter Cooner: >> >>> As a user of jOOQ, I frequently do >>> >>> MyTable t = Tables.MY_TABLE.as("T"); >>> >>> Before making use of any table, you'd still have to use the full path >>> when assigning it, but after that you could just reference the local >>> variable t. >>> >>> >>> >>> Pete >>> >>> >>> >>> On Tuesday, March 5, 2013 12:43:04 PM UTC-5, Matthias Fuchs wrote: >>>> >>>> Hi guys, >>>> >>>> first, this is a really great project! >>>> >>>> Currently I do a lot of data transfer jobs that basically fetch some >>>> data from DB1, transforms it and stores it in DB2. >>>> >>>> But there is one basic but very annoying bug: I can only import on >>>> Tables class reference and the second one (on DB2) has to be statically >>>> typed, e.g. at.ditech.shop.artikel.Tables. I know that I could simplify >>>> the >>>> package path but I like to have my code as java compliant as possible. And >>>> also I like the way eclipse creates a tree (in the package view) out of it. >>>> >>>> My first idea was to simply subclass Tables and give it a name like >>>> ShopTables. But this is currently not possible. >>>> Is there any other way of simplifying the access to this class? >>>> >>>> What we did today is to change the generator code to produce Tables >>>> classes with a public constructor, so know we can create this wrapper >>>> classes. >>>> >>>> But I'd really like to have an official way. Maybe you could include >>>> our code changes and make it an option. >>>> >>> -- >> 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/groups/opt_out. >> >> >> > > -- 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.
