Hi Joachim,
> You really mix Hibernate and JDBC (or Jooq) stuff within the same unit of
work?
> This didn't work too well for us; it's all too easy to have
cross-pollution between Hibernate
> and JDBC data (mostly caching problems, but sometimes issues with JDBC
data sent to helper
> functions that invoke Hibernate).
It does not work well unless you know the rules. We know these rules can be
crazy, that why we basically like the SQL way better and try to get there
(going the jOOQ path).
> I have mixed feelings about your use case; I can see that it is desired,
but I'd rather push people towards completing the migration...
Doing a full migration hibernate -> jOOQ just to demonstrate an idea will
not work in any any medium to large sized team / company / project.
You have to first convince people, e.g. by replacing time-critical pieces
and showing how cool jOOQ is. And in the end get the chance to use it and
assimilate some ORM code.
> , and having the ugliness of full qualification in the code helps with
that.
you try turning a disadvantage into an advantage. why put an artificial
constraint on code like a code nazi? People will hate you for that and
associate the mess with the introduction of jOOQ. Not the best start to
begin with.
> > convince the security team (optional),
> That should be easy. It's essentially just part of your set of build
tools.
that REALLY depends on the type of company. having to do serious amounts of
bureaucracy (even for a small module, especially in a bank or insurance
company) can easily be enough reason for a team leader to say 'no' to jOOQ.
just having stock jOOQ which works out-of-the-box will encounter the least
resistance.
> That's the "Maven way": if something doesn't fit into its (rather narrow)
definition of build lifecycle, fragment the project into mini projects that
each deploy to the repository.
And we all know how "great" the maven way(tm) sometimes is.
That will for out current project (and probably others) mean: restructure
the whole build in the VCS so the current one-pom-only project (~ 700.000
lines of code) will be a super-pom-project with one module being the
project and one module being a single file with one effective line
containing the naming strategy ('J' + super.get...() ). wow, that will be
pretty and people will just love it :-)
> If you don't want to go that route, Maven is not the right tool for your
situation
You should not confuse your personal pet project with a company project
being restricted by guidelines. These guidelines are sometimes nasty but
are there for a reason. for example a company often restricts the available
build tools so other developers can easily grok your project without having
to learn grade, buildr, sbt, etc. first. Available skill sometimes matters
more than decent technology.
Claiming another build tool just because the default naming strategy is not
fitting well will certainly be rejected (and I even fully support that
decision)
Honestly, all these things you mention (migrate the whole project from
hibernate to jOOQ, restructure your project for submodules, change the
build tools) are *imho* total overkill when all it takes is a simple
one-liner that probably will make many people with similar problems very
happy.
I think one goal of jOOQ should always be to keep things as simple as
possible. When adding a one-liner-class will potentially avoid all these
crazy steps above and attract more people, especially from the ORM
(hibernate, JPQ, eclipselink = many potential customers) world, it
certainly will be a good investment.
just my 2ct :-)
Cheers
Peter
--
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.
