> You may hit occasional issues with needing full qualification.
unfortunately it's not occasional at all... think about having a
CustomerDaoImpl where hibernate sits next to jOOQ. Having entity names
clash with jOOQ names would not be the exception but the norm. You would
have lots of explicit imports in the code:
[[some set up example]]
public class CustomerDaoImpl implements CustomerDao {
@Inject
private Session hibernateSession;
@Inject
private Executor jooqExecutor;
// ...
public void doHibernateAndJooqStuff() {
// first do some moderate cool hibernate stuff
Customer entity = new Customer(...);
// flush and clear session to avoid side effects to the loaded
entities
// and prepare for some huge data operation without all the bloat
session.flush();
session.clear();
// now do some extremely cool jOOQ stuff
org.mycorp.coolproduct.service.api.model.jooq.generated.Customer
customer = factory.select(...). /* ... */;
// ^ YUK ugly shit we have in here
// even uglier (will force line break on most screens)
org.mycorp.coolproduct.service.api.model.jooq.generated.Customer
customerReference =
org.mycorp.coolproduct.service.api.model.jooq.generated.Customer.CUSTOMER;
// do something with the reference
}
}
I know some people (including me) that would consider this amount of
explicit imports a no-go
> my recent experience with Maven indicates that sooner or later, you'll be
forced to use a repository manager anyway.
true. but we should not force people, when they consider switching from
e.g. hibernate to jOOQ (which is *good*), to first setup a nexus repo in
the company, convince the security team (optional), then install some tiny
one-liner-payload naming strategy using a separate project, run "mvn
deploy" with the proper account --> just to show off to the team how great
the migration to jOOQ would be :-)
^ hope you get the idea
Cheers
Peter
P.S.: The 'J' was meant to be a prefix for 'jOOQ', right!
Am Donnerstag, 28. März 2013 12:51:16 UTC+1 schrieb Joachim Durchholz:
>
> Please forgive me if I'm rehashing something already considered, I just
> noticed this one and didn't see previous messages.
>
> > - consider you use maven
> > - also consider that you mix jOOQ with something like
> > *brrr* hibernate / eclipselink / [any orm]
> >
> > -> chances are very, very high that the class names of
> > the entity classes (e.g. Customer.java -> mapped to
> > @Table "customer") will clash with the jOOQ generated
> > class 'Customer' when using the default strategy.
>
> Sure, but you could always generate the classes into separate packages.
> You may hit occasional issues with needing full qualification.
> The "Open Type" dialog in Eclipse isn't really a problem, you can type
> something like *pac*.Cu and you'll get classes with names like
> com.packaging.Customer.
>
> Not sure how this would interact with your Maven woes. I couldn't connect
> your problems to the situation you described (I probably missed something).
> The repository manager mention stuck out; my recent experience with Maven
> indicates that sooner or later, you'll be forced to use a repository
> manager anyway. I'm not sure that Jooq should accommodate merely postponing
> something that you'll have to do anyway.
> (I tried Maven recently, in the end decided it's too rigid to be adapted
> to the workflow and migrated to Gradle. Gradle came with its own set of
> road bumps, but in the end, it worked out okay.)
>
> Just my 2c.
>
> Regards,
> Jo
>
--
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.
