JaQu status

[bart]

Hi,

I am seriously considering to use JaQu in a project quite big.
I would like to know the current status of JaQu next to :
- issue 286: Enhancements to JaQu (Patch)
- issue 298: JaQu concurrency patch
- the changes proposed by Shai in this thread
http://groups.google.com/group/h2-database/browse_thread/thread/52182521e64be57b/f014c6662420bebb

Regards,

bart

[Ryan How]

I don't know about those issues, but I've been using JaQu in quite a
decent sized project. It is great for doing things quickly. Much quicker
than writing JDBC, but not as powerful as something like hibernate. I
rather prefer using ids and linking using that rather than having it
automatically link. If I was going that path I think I would rather use
hibernate. So I think of it like a quick and easy way to do SQL rather
than an ORM.

[James Moger]

The patch in issue 286 was merged into trunk in early Spring.
The concurrency patch in issue 298 has NOT been merged, but IMHO should be.
AFAIK, nothing from Shai ever materialized.

JaQu is a nice tool.  Its just enough to be useful but not enough to be complex.

Rather than sitting dormant in SVN perhaps Thomas might consider graduating it and releasing binaries.
Being able to retrieve JaQu jars from Maven would be especially nice.

-J

[Thomas Mueller]

Hi,

Maybe it would make sense from those who are interested to fork it...
I'm not sure if it does make sense, but it would be an option.

Regards,
Thomas

[Lukas Eder]

> Maybe it would make sense from those who are interested to fork it...
> I'm not sure if it does make sense, but it would be an option.

I had previously thought about integrating some central features
(especially the natural syntax) in jOOQ (http://www.jooq.org). This
thread here makes me think whether it might be a reasonable idea to
actually merge JaQu and jOOQ? Both projects could gain from the
synergies and increased communities.

- JaQu's strength: "natural" Java syntax. Writing SQL feels much more
like writing Java
- jOOQ's strength: rich with complex SQL features (also vendor-
specific ones) from many RDBMS

Both ship with a similar, intuitive fluent API

[shai]

Seem to have posted this wrong on the list so I'm sorry if this is a
duplicate.

Since Thomas did not want to go down the path I wanted I never
integrated my stuff with the original Jaqu. I do have however my own
version. I've been using Jaqu for a long time now in small and large
projects.

As I mentioned in my mail I have adapted it to replace hibernate for
me.
It handles all object relationships on entities and allows for all
other
good things you get with Jaqu on Pojos at the same time. In order to
acheive this I did use some post compilation byte code adjustments and
for that I also wrote an eclipse plugin. I've never shared my
adjustments with anyone yet so I don't know how simple this may be for
someone else to use. Bare in mind that in order to use my changes you
will need to use annotations in runtime.

Shai

On Jun 30, 10:52 am, bart <gaill...@audemat.com> wrote:
> Hi,
>
> I am seriously considering  to use JaQu in a project quite big.
> I would like to know the current status of JaQu next to :
> - issue 286: Enhancements to JaQu (Patch)
> - issue 298: JaQu concurrency patch

> - the changes proposed by Shai in this threadhttp://groups.google.com/group/h2-database/browse_thread/thread/52182...
>
> Regards,
>
> bart

[bart]

First I want to thank you all for your answers
My first motivation to use JaQu is related to this article :
http://itroman.wordpress.com/2010/12/05/why-i-do-hate-hibernate/
I agree with most of what is written.
I'm looking for a simple, reliable tool and JaQu seems to me now the
one with most of those qualities.
I am also interested in jOOQ, but just reading the documentation I was
a little skeptical with respect to the simplicity of JaQu.
However the management of different types of databases is interesting.
I do not seek a new ORM, I just want to code efficiently in Java and
use a database in a highly concurrent environment.
The natural java syntax of JaQu is a real 'plus' for me but it's only
my opignon.

Regards,

bart

[cowwoc]

On 30/06/2011 3:11 PM, bart wrote:
> However the management of different types of databases is interesting.

My 2 cents: don't bother. You're chasing a false dream (no one has
solved this problem yet). And if you think about it, how often do you
really need to change databases? This is only useful for products that
need to support multiple databases concurrently.

Gili

[Shai Bentin]

Hey,

You can see my stuff here: http://code.google.com/p/jaqu-orm/
post you questions on the wiki pages, post issues on the site's issues.

Shai

בתאריך 30/06/11 11:14 PM, ציטוט cowwoc:

[Rami Ojares]

It is fairly simple to write a thin typology layer in java (yes I have
done it) that
shows the db types in a unified way to a java program.
My current typology includes the types
BOOLEAN, INTEGER, FLOATING, DECIMAL, STRING, BINARY, TEMPORAL and EXOTIC

Into exotic I have thrown everything confusing that I dislike (eg. Array)

But that will not help when accessing the db from non-java programs.
Also it will not fix the inconsistencies in the type system of the
underlying db.

One thing to note is that a layer on top of another is at it's best as
good as the layer below it.
That's why I choose to use jdbc and sql with H2 because if that is not
very satisfying how
can a layer above it be so?

To me Jaqu's, JooQ's and hibernate's etc. query languages are even more
confusing and difficult
than sql (which is illogical and bureaucratic to begin with).

For me the proliferation of layers above layers is the real problem of
why things are so difficult
to grasp nowadays in the java world.

Just my 5 cents.

- rami

[Thotheolh]

If the project requires lots of SQL feature that H2's SQL provides,
then go with SQL. If you need a very small subset of functions that
JaQu can do well in (CRUD), go for JaQu (at your own risk). In the
end, I felt that SQL would be the best but JaQu would enable writing
your transactions in a more Java-like way but it restricts
flexibility.

On Jun 30, 3:52 pm, bart <gaill...@audemat.com> wrote:
> Hi,
>
> I am seriously considering  to use JaQu in a project quite big.
> I would like to know the current status of JaQu next to :
> - issue 286: Enhancements to JaQu (Patch)
> - issue 298: JaQu concurrency patch

> - the changes proposed by Shai in this threadhttp://groups.google.com/group/h2-database/browse_thread/thread/52182...
>
> Regards,
>
> bart

[Lukas Eder]

There's no best way to do things... There are only individually
preferred ways and then tools / standards (mostly tools that have
become standards) that support you in doing what you want. And then,
there are success stories with every way, and that's what makes life
interesting.

I wouldn't be too mad about layering in todays software world. JDBC
itself is a layer on top of any arbitrary proprietary RDBMS
communication protocol, which itself is again based on TCP/IP, which
in turn is layered on top of other network layers. Then again, JDBC is
very simple for good reasons: With its simplicity, arbitrary
proprietary SQL is supported - for instance H2's MERGE statement. So
using plain JDBC is perfectly OK. But the nature of JDBC makes you
write repetitive code (and mistakes), a problem that is not addressed
in JDBC for those reasons. That problem is supposed to be addressed in
higher-level layers... (like TCP addresses problems that IP might
cause, if used "standalone").

Typesafety and CRUD are problem not addresses by JDBC...

[James Moger]

I wanted to post an update on issue-298 (concurrency patch) and say that my proposed changes to TableDefinition to allow concurrent re-use of an alias object (i.e. Db.from(ALIAS) ) work, BUT they create other problems so I no longer advocate those adjustments.  :(

The other simple changes in the patch allow for concurrent re-use of a Db object and I think those are still good.

-J

[bart]

When I asked my question about the status of James, I did not think it
would raise as many comments.
I'm glad to see that Shai has posted his modifications, the management
of differents types of databases seem to me quite good.
ORM side, I think the proposed changes introduced too many constraints
and changes for a low gain in the use.
Thomas, could you clarify the direction you want to take with JaQu ?
Support for multiple databases seems to be a good choice without
introducing too much complexity.

Regards,

bart

[James Moger]

JaQu in SVN has the option to define a custom dialect for a particular database.  Currently there is only one implementation of SQLDialect and that is for H2.  For supporting other DBs you should start there.

You should also be aware that JaQu has some H2 class dependencies so at present it requires the H2 jar as well (1.3MB).  Its not hard to remove these dependencies.   It also shouldn't be hard to adjust the build definition to make a stand-alone JaQu although last time I tried that approach, JaQu ended up needing way more of H2 than it really should have because of class verification errors of the pulled-in dependencies.

[bart]

Thank you for this information James, but I already read all the code
of JaQu and I'm not a novice in Java.
I want to have the point of view from Thomas because it's his project
and he's someone I respect for all the work he did.
I'm a user of the first hour of HyperSonicSQL and while we believe all
have a talent that of Thomas is recognized for a long time.
I do not want to be rude so do not be too hard on me ;-)

Regards,

bart

[Thomas Mueller]

Hi,

> I want to have the point of view from Thomas because it's his project
> and he's someone I respect for all the work he did.

I would really like to comment, and help further improve JaQu, but I'm afraid I will not have time to do so in the near future. So far, I did not even have enough time to integrate all the changes from James. It doesn't look good in the near future.

So I guess it makes sense for those who are interested to create a new project. I don't want to hold up anybody. If such a new project would like a different license (for example Apache), then I would be happy to allow that. The project would need a new name I guess, as I would like to keep the name 'JaQu' currently. I will then point to this new project from the JaQu page, and possibly even retire my project later on (but more likely, I will keep JaQu as it is now for some time).

Regards,
Thomas