An excercise inspired by empire-db

[Marcio Mazza <ma...@gmail.com>]

I recently took a a 2 week vacation to make a little exercise inspired by
empire-db.

It is here:
https://github.com/marciomazza/miniquery

Everything is experimental, but maybe you can see some of the design
through.
I do not have much time to work on that anymore... so I bring this to you
now.
My motivation was to make a minimal API (much smaller than that of
empire-db).
It borrows from empire-db the idea of expressing the database metadata in
code, which I think is really great. Try to see the differences in design,
though.

Now... the *feedback*:

One may wonder why didn't I stick to empire-db, instead of trying to write
something on my own.
Two main reasons come to my mind now:

1) Empire-db's scope is much bigger than what I wanted.

  I indeed think you could have a smaller kernel, with just the basic SQL
operations, leveraging just the idea of "metadata in code" and nothing more.
Everything else should be pluggable and optional.

2) Empire-db's kernel is not strictly portable between the supported
vendors. (One of the key advantages of Hibernate :P... oh... that name
revolves my stomach).

3) Empire-db does not have good automated test coverage.

  Although Donald Knuth does not consider this to be a problem, I do believe
that an open source project that wants to really gather new contribution
cannot succeed without it. The reason is simple. Once a contribution is
made, everything should be tested. The knowledge of what should be tested,
and how, should be readly available to that very contributor. And, to be
nice and inviting, that test knowledge should be automated.
  Actually I saw very little tests. You have to go much further and dive to
the degree of deep integration testing, to run the same tests against
different database instances automatically. That's an interesting thing.

4) Empire-db didn't have simple and direct pagination support. I see you've
been implementing that. This is too basic a thing for web apps and I think
should be a priority.


Those are my opinions and my feedback. They were written in very good will.
The success of Empire-db is in my best interest. The java community needs
this approach.

[]'s
Mazza.

Re: An excercise inspired by empire-db

[Marcio Mazza <ma...@gmail.com>]

Well... one should read "4 main reasons" instead of 2... They silently grew
while I wrote.

They should be 3, actually, since pagination support (limit) seems easy to
solve.


2011/4/13 Marcio Mazza <ma...@gmail.com>

> I recently took a a 2 week vacation to make a little exercise inspired by
> empire-db.
>
> It is here:
> https://github.com/marciomazza/miniquery
>
> Everything is experimental, but maybe you can see some of the design
> through.
> I do not have much time to work on that anymore... so I bring this to you
> now.
> My motivation was to make a minimal API (much smaller than that of
> empire-db).
> It borrows from empire-db the idea of expressing the database metadata in
> code, which I think is really great. Try to see the differences in design,
> though.
>
> Now... the *feedback*:
>
> One may wonder why didn't I stick to empire-db, instead of trying to write
> something on my own.
> Two main reasons come to my mind now:
>
> 1) Empire-db's scope is much bigger than what I wanted.
>
>   I indeed think you could have a smaller kernel, with just the basic SQL
> operations, leveraging just the idea of "metadata in code" and nothing more.
> Everything else should be pluggable and optional.
>
> 2) Empire-db's kernel is not strictly portable between the supported
> vendors. (One of the key advantages of Hibernate :P... oh... that name
> revolves my stomach).
>
> 3) Empire-db does not have good automated test coverage.
>
>   Although Donald Knuth does not consider this to be a problem, I do
> believe that an open source project that wants to really gather new
> contribution cannot succeed without it. The reason is simple. Once a
> contribution is made, everything should be tested. The knowledge of what
> should be tested, and how, should be readly available to that very
> contributor. And, to be nice and inviting, that test knowledge should be
> automated.
>   Actually I saw very little tests. You have to go much further and dive to
> the degree of deep integration testing, to run the same tests against
> different database instances automatically. That's an interesting thing.
>
> 4) Empire-db didn't have simple and direct pagination support. I see you've
> been implementing that. This is too basic a thing for web apps and I think
> should be a priority.
>
>
> Those are my opinions and my feedback. They were written in very good will.
> The success of Empire-db is in my best interest. The java community needs
> this approach.
>
> []'s
> Mazza.
>
>