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].
For more options, visit https://groups.google.com/groups/opt_out.
