You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@empire-db.apache.org by bachew <ap...@gmail.com> on 2009/01/30 03:18:39 UTC

More history of Empire-db

Hi,
The first entry in the FAQ answered part of my question -
http://incubator.apache.org/empire-db/empiredb/faq.htm. But I would like to
know more about the history of Empire-db, the people and the organization
behind this interesting library. How it improves over the years and what
kinda applications that Empire-db is written for. And erm... why name it
Empire-db?

Hard to believe that someone finally did what I have in mind and this
page<http://incubator.apache.org/empire-db/empiredb/hibernate.htm>explained
what I always wanted to explain to people. I'm planning to write
an application framework and it seems my only choice is Empire-db on
database side, I wish to know more about it.

Thanks in advance.

Re: More history of Empire-db

Posted by bachew <ap...@gmail.com>.
Yup, not over-complicated but simply intuitive is what I after. The reason I
find Empire-db more appealing than static configuration based persistence
framework is the same for Wicket vs Struts2. I'm not sure how good
empire-db-struts2 is but I'm definitely not going to bother much on template
based web framework.
Unfortunately I haven't started anything yet, so can't provide much feedback
to you guys. I'm sure to keep you all updated.

On Thu, Feb 5, 2009 at 7:40 PM, Rainer Döbele <do...@esteam.de> wrote:

> Hi bachew,
>
> yes sounds interesting, although with so many frameworks to have to carful
> not to make things over-complicated.
>
> Redarding wicket: I think Wicket and Empire-db could be a very good
> combination. We had a student who was willing to this for his dissertation
> project but unfortunately he could't find a professor for this topic and had
> to take something else.
>
> The basic approach for Wicket could be similar to the one we've taken for
> our Struts2 intergration.
> If you need any assistence here I might be able to provide you with some
> useful hints.
>
> Rainer
>
> > -----Ursprüngliche Nachricht-----
> > Von: Francis De Brabandere [mailto:francisdb@gmail.com]
> > Gesendet: Montag, 2. Februar 2009 13:22
> > An: empire-db-user@incubator.apache.org
> > Betreff: Re: More history of Empire-db
> >
> > Hi bachew,
> >
> > Interesting to see you're integrating Wicket and Empire-db, I'd like
> > to know how you are handling the integration. Keep us updated on your
> > progress!
> >
> > On Mon, Feb 2, 2009 at 8:21 AM, bachew <ap...@gmail.com> wrote:
> > > Hi,
> > > Thanks for the details. Actually as an sane object oriented programmer
> > came
> > > from C++ like you, I understand that API is above everything, metadata
> > > (annotation and XML) are very well just implemented using API. To use
> > JPA
> > > would mean I'm stuck without the ability to intuitively get metadata in
> > > runtime. People were trying to pretend that SQL does not exist, but we
> > all
> > > know it will exist for a very long time.
> > > I need SQL abstraction library but I don't have the time to write it,
> > > Empire-db looks exactly what I need, I haven't tried it though, will
> try
> > > once I'm back from holiday and finished up tasks at hands.
> > > Actually I have been gathering like-minded projects, like-minded in
> > terms of
> > > focus on getting API right, making most, if not everything dynamic.
> > We've
> > > got Guice for dependency injection, Wicket for web framework, Jetty for
> > > embedded web server, Restlet for REST service and hopefully Empire-db
> > for
> > > database.
> > >
> > > I'm not building something sophisticated, just want a real object
> > oriented
> > > Java application framework to save our fellow Java developers precious
> > time.
> > > It's simply sickening for me to maintain someone else's applications
> > written
> > > in JPA, struts, JSP, JSF, spring moster xml, etc.
> > > On Sun, Feb 1, 2009 at 6:39 PM, Rainer Döbele <do...@esteam.de>
> wrote:
> > >>
> > >> Hi bachew,
> > >>
> > >> we're glad to hear that you like Empire-db. We really believe it's the
> > >> best thing since sliced bread and we hope more and more people will
> see
> > the
> > >> advantages.
> > >>
> > >> About the history:
> > >> The basic idea, i.e. to describe the data model using classes and
> > objects
> > >> goes back to the middle of the 90's. At that time I was developing
> > document
> > >> management solutions under Windows using C++ and MFC. Back then I
> wrote
> > the
> > >> first attempt for a relational data persistence layer in C++.
> > >>
> > >> In 2000 me and my partner founded our company ESTEAM Software now
> > focusing
> > >> on developing Web-based applications in Java. For our first big
> project
> > I
> > >> used all the ideas from my C++ implementation to build a data
> > persistence
> > >> layer in Java. Since then we have used and improved the library (I
> > don't
> > >> want to use the word 'framework' in this context) in many
> fundamentally
> > >> different applications such as CRM-tools, DataWarehouse utilities,
> > >> Supply-Chain-Management etc. and for both Web and Rich-Client
> > applications.
> > >> Besides the Java implementation we also have a C# implementation;
> > however we
> > >> have not yet found the time to separate it from other stuff and make
> > the
> > >> necessary refactorings to match it with our Java Empire-db. We might
> do
> > that
> > >> I we find there is demand for it.
> > >>
> > >> Most applications that we have implemented were relying heavily on
> data
> > >> gathered from various tables by complex queries with varying
> > constraints and
> > >> joins which are built at runtime. Also as applications and data model
> > change
> > >> we needed something that gives us maximum security that when we change
> > the
> > >> model the application will still work - or the compiler should give us
> > an
> > >> error. This is why we tried to avoid using strings for column or table
> > names
> > >> completely - except for the model definition of course.
> > >> This has many times saved our lives and I really can't see how people
> > >> could possibly survive with traditional OR-Mappers except for the
> > simplest
> > >> type of database activity.
> > >>
> > >> Finally about the name:
> > >> This is a rather boring story. First, as we had the 'e' for our
> jsp-tag
> > >> library originally taken from our company name "ESTEAM" we were
> looking
> > for
> > >> a name that also started with an 'e'. Second it had to be a simple
> word
> > as
> > >> we couldn't think of a suitable idiom. And finally since my kids have
> > made
> > >> me live in a parallel Star Wars universe for the last couple of years
> > >> "Empire" was the closest match. We're not looking to become as bad as
> > the
> > >> Galactic Empire though. So far we're only just rebels in the universe
> > of
> > >> relational data persistence. But we're determined to take on all these
> > >> Hibernates and JPA implementations out there and maybe one day we will
> > make
> > >> the world a better place :-)
> > >>
> > >> The two example applications provided with the core and the web-demo
> > >> application provided with the struts extensions should give you a good
> > idea
> > >> about most of the functionality and how to apply it. However most
> > people
> > >> when starting to use Empire-db make things more complicated than
> > necessary.
> > >> So if you face any difficulties or think there must be a shorter
> easier
> > way
> > >> to achieve something don't hesitate to ask.
> > >>
> > >> On the other hand we are curious to hear what kind of solution you
> have
> > >> implemented with Empire-db.
> > >> Best regards
> > >>
> > >>
> > >> Rainer
> > >>
> > >>
> > >> bachew wrote on Fr 30.01.2009 03:18
> > >> > Re: More history of Empire-db
> > >> >
> > >> > Hi,
> > >> > The first entry in the FAQ answered part of my question -
> > >> > http://incubator.apache.org/empire-db/empiredb/faq.htm. But I would
> > like
> > >> > to
> > >> > know more about the history of Empire-db, the people and the
> > >> > organization
> > >> > behind this interesting library. How it improves over the years and
> > what
> > >> > kinda applications that Empire-db is written for. And erm... why
> name
> > it
> > >> > Empire-db?
> > >> >
> > >> > Hard to believe that someone finally did what I have in mind and
> this
> > >> >
> > >> > page<http://incubator.apache.org/empire-
> > db/empiredb/hibernate.htm>explained
> > >> > what I always wanted to explain to people. I'm planning to write
> > >> > an application framework and it seems my only choice is Empire-db on
> > >> > database side, I wish to know more about it.
> > >> >
> > >> > Thanks in advance.
> > >> >
> > >
> > >
> >
> >
> >
> > --
> > http://www.somatik.be
> > Microsoft gives you windows, Linux gives you the whole house.
>

Re: More history of Empire-db

Posted by Rainer Döbele <do...@esteam.de>.
Hi bachew,

yes sounds interesting, although with so many frameworks to have to carful not to make things over-complicated. 

Redarding wicket: I think Wicket and Empire-db could be a very good combination. We had a student who was willing to this for his dissertation project but unfortunately he could't find a professor for this topic and had to take something else.

The basic approach for Wicket could be similar to the one we've taken for our Struts2 intergration.
If you need any assistence here I might be able to provide you with some useful hints.

Rainer

> -----Ursprüngliche Nachricht-----
> Von: Francis De Brabandere [mailto:francisdb@gmail.com]
> Gesendet: Montag, 2. Februar 2009 13:22
> An: empire-db-user@incubator.apache.org
> Betreff: Re: More history of Empire-db
> 
> Hi bachew,
> 
> Interesting to see you're integrating Wicket and Empire-db, I'd like
> to know how you are handling the integration. Keep us updated on your
> progress!
> 
> On Mon, Feb 2, 2009 at 8:21 AM, bachew <ap...@gmail.com> wrote:
> > Hi,
> > Thanks for the details. Actually as an sane object oriented programmer
> came
> > from C++ like you, I understand that API is above everything, metadata
> > (annotation and XML) are very well just implemented using API. To use
> JPA
> > would mean I'm stuck without the ability to intuitively get metadata in
> > runtime. People were trying to pretend that SQL does not exist, but we
> all
> > know it will exist for a very long time.
> > I need SQL abstraction library but I don't have the time to write it,
> > Empire-db looks exactly what I need, I haven't tried it though, will try
> > once I'm back from holiday and finished up tasks at hands.
> > Actually I have been gathering like-minded projects, like-minded in
> terms of
> > focus on getting API right, making most, if not everything dynamic.
> We've
> > got Guice for dependency injection, Wicket for web framework, Jetty for
> > embedded web server, Restlet for REST service and hopefully Empire-db
> for
> > database.
> >
> > I'm not building something sophisticated, just want a real object
> oriented
> > Java application framework to save our fellow Java developers precious
> time.
> > It's simply sickening for me to maintain someone else's applications
> written
> > in JPA, struts, JSP, JSF, spring moster xml, etc.
> > On Sun, Feb 1, 2009 at 6:39 PM, Rainer Döbele <do...@esteam.de> wrote:
> >>
> >> Hi bachew,
> >>
> >> we're glad to hear that you like Empire-db. We really believe it's the
> >> best thing since sliced bread and we hope more and more people will see
> the
> >> advantages.
> >>
> >> About the history:
> >> The basic idea, i.e. to describe the data model using classes and
> objects
> >> goes back to the middle of the 90's. At that time I was developing
> document
> >> management solutions under Windows using C++ and MFC. Back then I wrote
> the
> >> first attempt for a relational data persistence layer in C++.
> >>
> >> In 2000 me and my partner founded our company ESTEAM Software now
> focusing
> >> on developing Web-based applications in Java. For our first big project
> I
> >> used all the ideas from my C++ implementation to build a data
> persistence
> >> layer in Java. Since then we have used and improved the library (I
> don't
> >> want to use the word 'framework' in this context) in many fundamentally
> >> different applications such as CRM-tools, DataWarehouse utilities,
> >> Supply-Chain-Management etc. and for both Web and Rich-Client
> applications.
> >> Besides the Java implementation we also have a C# implementation;
> however we
> >> have not yet found the time to separate it from other stuff and make
> the
> >> necessary refactorings to match it with our Java Empire-db. We might do
> that
> >> I we find there is demand for it.
> >>
> >> Most applications that we have implemented were relying heavily on data
> >> gathered from various tables by complex queries with varying
> constraints and
> >> joins which are built at runtime. Also as applications and data model
> change
> >> we needed something that gives us maximum security that when we change
> the
> >> model the application will still work - or the compiler should give us
> an
> >> error. This is why we tried to avoid using strings for column or table
> names
> >> completely - except for the model definition of course.
> >> This has many times saved our lives and I really can't see how people
> >> could possibly survive with traditional OR-Mappers except for the
> simplest
> >> type of database activity.
> >>
> >> Finally about the name:
> >> This is a rather boring story. First, as we had the 'e' for our jsp-tag
> >> library originally taken from our company name "ESTEAM" we were looking
> for
> >> a name that also started with an 'e'. Second it had to be a simple word
> as
> >> we couldn't think of a suitable idiom. And finally since my kids have
> made
> >> me live in a parallel Star Wars universe for the last couple of years
> >> "Empire" was the closest match. We're not looking to become as bad as
> the
> >> Galactic Empire though. So far we're only just rebels in the universe
> of
> >> relational data persistence. But we're determined to take on all these
> >> Hibernates and JPA implementations out there and maybe one day we will
> make
> >> the world a better place :-)
> >>
> >> The two example applications provided with the core and the web-demo
> >> application provided with the struts extensions should give you a good
> idea
> >> about most of the functionality and how to apply it. However most
> people
> >> when starting to use Empire-db make things more complicated than
> necessary.
> >> So if you face any difficulties or think there must be a shorter easier
> way
> >> to achieve something don't hesitate to ask.
> >>
> >> On the other hand we are curious to hear what kind of solution you have
> >> implemented with Empire-db.
> >> Best regards
> >>
> >>
> >> Rainer
> >>
> >>
> >> bachew wrote on Fr 30.01.2009 03:18
> >> > Re: More history of Empire-db
> >> >
> >> > Hi,
> >> > The first entry in the FAQ answered part of my question -
> >> > http://incubator.apache.org/empire-db/empiredb/faq.htm. But I would
> like
> >> > to
> >> > know more about the history of Empire-db, the people and the
> >> > organization
> >> > behind this interesting library. How it improves over the years and
> what
> >> > kinda applications that Empire-db is written for. And erm... why name
> it
> >> > Empire-db?
> >> >
> >> > Hard to believe that someone finally did what I have in mind and this
> >> >
> >> > page<http://incubator.apache.org/empire-
> db/empiredb/hibernate.htm>explained
> >> > what I always wanted to explain to people. I'm planning to write
> >> > an application framework and it seems my only choice is Empire-db on
> >> > database side, I wish to know more about it.
> >> >
> >> > Thanks in advance.
> >> >
> >
> >
> 
> 
> 
> --
> http://www.somatik.be
> Microsoft gives you windows, Linux gives you the whole house.

Re: More history of Empire-db

Posted by Francis De Brabandere <fr...@gmail.com>.
Hi bachew,

Interesting to see you're integrating Wicket and Empire-db, I'd like
to know how you are handling the integration. Keep us updated on your
progress!

On Mon, Feb 2, 2009 at 8:21 AM, bachew <ap...@gmail.com> wrote:
> Hi,
> Thanks for the details. Actually as an sane object oriented programmer came
> from C++ like you, I understand that API is above everything, metadata
> (annotation and XML) are very well just implemented using API. To use JPA
> would mean I'm stuck without the ability to intuitively get metadata in
> runtime. People were trying to pretend that SQL does not exist, but we all
> know it will exist for a very long time.
> I need SQL abstraction library but I don't have the time to write it,
> Empire-db looks exactly what I need, I haven't tried it though, will try
> once I'm back from holiday and finished up tasks at hands.
> Actually I have been gathering like-minded projects, like-minded in terms of
> focus on getting API right, making most, if not everything dynamic. We've
> got Guice for dependency injection, Wicket for web framework, Jetty for
> embedded web server, Restlet for REST service and hopefully Empire-db for
> database.
>
> I'm not building something sophisticated, just want a real object oriented
> Java application framework to save our fellow Java developers precious time.
> It's simply sickening for me to maintain someone else's applications written
> in JPA, struts, JSP, JSF, spring moster xml, etc.
> On Sun, Feb 1, 2009 at 6:39 PM, Rainer Döbele <do...@esteam.de> wrote:
>>
>> Hi bachew,
>>
>> we're glad to hear that you like Empire-db. We really believe it's the
>> best thing since sliced bread and we hope more and more people will see the
>> advantages.
>>
>> About the history:
>> The basic idea, i.e. to describe the data model using classes and objects
>> goes back to the middle of the 90's. At that time I was developing document
>> management solutions under Windows using C++ and MFC. Back then I wrote the
>> first attempt for a relational data persistence layer in C++.
>>
>> In 2000 me and my partner founded our company ESTEAM Software now focusing
>> on developing Web-based applications in Java. For our first big project I
>> used all the ideas from my C++ implementation to build a data persistence
>> layer in Java. Since then we have used and improved the library (I don't
>> want to use the word 'framework' in this context) in many fundamentally
>> different applications such as CRM-tools, DataWarehouse utilities,
>> Supply-Chain-Management etc. and for both Web and Rich-Client applications.
>> Besides the Java implementation we also have a C# implementation; however we
>> have not yet found the time to separate it from other stuff and make the
>> necessary refactorings to match it with our Java Empire-db. We might do that
>> I we find there is demand for it.
>>
>> Most applications that we have implemented were relying heavily on data
>> gathered from various tables by complex queries with varying constraints and
>> joins which are built at runtime. Also as applications and data model change
>> we needed something that gives us maximum security that when we change the
>> model the application will still work - or the compiler should give us an
>> error. This is why we tried to avoid using strings for column or table names
>> completely - except for the model definition of course.
>> This has many times saved our lives and I really can't see how people
>> could possibly survive with traditional OR-Mappers except for the simplest
>> type of database activity.
>>
>> Finally about the name:
>> This is a rather boring story. First, as we had the 'e' for our jsp-tag
>> library originally taken from our company name "ESTEAM" we were looking for
>> a name that also started with an 'e'. Second it had to be a simple word as
>> we couldn't think of a suitable idiom. And finally since my kids have made
>> me live in a parallel Star Wars universe for the last couple of years
>> "Empire" was the closest match. We're not looking to become as bad as the
>> Galactic Empire though. So far we're only just rebels in the universe of
>> relational data persistence. But we're determined to take on all these
>> Hibernates and JPA implementations out there and maybe one day we will make
>> the world a better place :-)
>>
>> The two example applications provided with the core and the web-demo
>> application provided with the struts extensions should give you a good idea
>> about most of the functionality and how to apply it. However most people
>> when starting to use Empire-db make things more complicated than necessary.
>> So if you face any difficulties or think there must be a shorter easier way
>> to achieve something don't hesitate to ask.
>>
>> On the other hand we are curious to hear what kind of solution you have
>> implemented with Empire-db.
>> Best regards
>>
>>
>> Rainer
>>
>>
>> bachew wrote on Fr 30.01.2009 03:18
>> > Re: More history of Empire-db
>> >
>> > Hi,
>> > The first entry in the FAQ answered part of my question -
>> > http://incubator.apache.org/empire-db/empiredb/faq.htm. But I would like
>> > to
>> > know more about the history of Empire-db, the people and the
>> > organization
>> > behind this interesting library. How it improves over the years and what
>> > kinda applications that Empire-db is written for. And erm... why name it
>> > Empire-db?
>> >
>> > Hard to believe that someone finally did what I have in mind and this
>> >
>> > page<http://incubator.apache.org/empire-db/empiredb/hibernate.htm>explained
>> > what I always wanted to explain to people. I'm planning to write
>> > an application framework and it seems my only choice is Empire-db on
>> > database side, I wish to know more about it.
>> >
>> > Thanks in advance.
>> >
>
>



-- 
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.

Re: More history of Empire-db

Posted by bachew <ap...@gmail.com>.
Hi,

Thanks for the details. Actually as an sane object oriented programmer came
from C++ like you, I understand that API is above everything, metadata
(annotation and XML) are very well just implemented using API. To use JPA
would mean I'm stuck without the ability to intuitively get metadata in
runtime. People were trying to pretend that SQL does not exist, but we all
know it will exist for a very long time.
I need SQL abstraction library but I don't have the time to write it,
Empire-db looks exactly what I need, I haven't tried it though, will try
once I'm back from holiday and finished up tasks at hands.

Actually I have been gathering like-minded projects, like-minded in terms of
focus on getting API right, making most, if not everything dynamic. We've
got Guice for dependency injection, Wicket for web framework, Jetty for
embedded web server, Restlet for REST service and hopefully Empire-db for
database.

I'm not building something sophisticated, just want a real object oriented
Java application framework to save our fellow Java developers precious time.
It's simply sickening for me to maintain someone else's applications written
in JPA, struts, JSP, JSF, spring moster xml, etc.

On Sun, Feb 1, 2009 at 6:39 PM, Rainer Döbele <do...@esteam.de> wrote:

> Hi bachew,
>
> we're glad to hear that you like Empire-db. We really believe it's the best
> thing since sliced bread and we hope more and more people will see the
> advantages.
>
> About the history:
> The basic idea, i.e. to describe the data model using classes and objects
> goes back to the middle of the 90's. At that time I was developing document
> management solutions under Windows using C++ and MFC. Back then I wrote the
> first attempt for a relational data persistence layer in C++.
>
> In 2000 me and my partner founded our company ESTEAM Software now focusing
> on developing Web-based applications in Java. For our first big project I
> used all the ideas from my C++ implementation to build a data persistence
> layer in Java. Since then we have used and improved the library (I don't
> want to use the word 'framework' in this context) in many fundamentally
> different applications such as CRM-tools, DataWarehouse utilities,
> Supply-Chain-Management etc. and for both Web and Rich-Client applications.
> Besides the Java implementation we also have a C# implementation; however we
> have not yet found the time to separate it from other stuff and make the
> necessary refactorings to match it with our Java Empire-db. We might do that
> I we find there is demand for it.
>
> Most applications that we have implemented were relying heavily on data
> gathered from various tables by complex queries with varying constraints and
> joins which are built at runtime. Also as applications and data model change
> we needed something that gives us maximum security that when we change the
> model the application will still work - or the compiler should give us an
> error. This is why we tried to avoid using strings for column or table names
> completely - except for the model definition of course.
> This has many times saved our lives and I really can't see how people could
> possibly survive with traditional OR-Mappers except for the simplest type of
> database activity.
>
> Finally about the name:
> This is a rather boring story. First, as we had the 'e' for our jsp-tag
> library originally taken from our company name "ESTEAM" we were looking for
> a name that also started with an 'e'. Second it had to be a simple word as
> we couldn't think of a suitable idiom. And finally since my kids have made
> me live in a parallel Star Wars universe for the last couple of years
> "Empire" was the closest match. We're not looking to become as bad as the
> Galactic Empire though. So far we're only just rebels in the universe of
> relational data persistence. But we're determined to take on all these
> Hibernates and JPA implementations out there and maybe one day we will make
> the world a better place :-)
>
> The two example applications provided with the core and the web-demo
> application provided with the struts extensions should give you a good idea
> about most of the functionality and how to apply it. However most people
> when starting to use Empire-db make things more complicated than necessary.
> So if you face any difficulties or think there must be a shorter easier way
> to achieve something don't hesitate to ask.
>
> On the other hand we are curious to hear what kind of solution you have
> implemented with Empire-db.
> Best regards
>
>
> Rainer
>
>
> bachew wrote on Fr 30.01.2009 03:18
> > Re: More history of Empire-db
> >
> > Hi,
> > The first entry in the FAQ answered part of my question -
> > http://incubator.apache.org/empire-db/empiredb/faq.htm. But I would like
> to
> > know more about the history of Empire-db, the people and the organization
> > behind this interesting library. How it improves over the years and what
> > kinda applications that Empire-db is written for. And erm... why name it
> > Empire-db?
> >
> > Hard to believe that someone finally did what I have in mind and this
> > page<http://incubator.apache.org/empire-db/empiredb/hibernate.htm
> >explained
> > what I always wanted to explain to people. I'm planning to write
> > an application framework and it seems my only choice is Empire-db on
> > database side, I wish to know more about it.
> >
> > Thanks in advance.
> >
>

re: More history of Empire-db

Posted by Rainer Döbele <do...@esteam.de>.
Hi bachew,

we’re glad to hear that you like Empire-db. We really believe it's the best thing since sliced bread and we hope more and more people will see the advantages.

About the history:
The basic idea, i.e. to describe the data model using classes and objects goes back to the middle of the 90's. At that time I was developing document management solutions under Windows using C++ and MFC. Back then I wrote the first attempt for a relational data persistence layer in C++. 

In 2000 me and my partner founded our company ESTEAM Software now focusing on developing Web-based applications in Java. For our first big project I used all the ideas from my C++ implementation to build a data persistence layer in Java. Since then we have used and improved the library (I don't want to use the word 'framework' in this context) in many fundamentally different applications such as CRM-tools, DataWarehouse utilities, Supply-Chain-Management etc. and for both Web and Rich-Client applications. Besides the Java implementation we also have a C# implementation; however we have not yet found the time to separate it from other stuff and make the necessary refactorings to match it with our Java Empire-db. We might do that I we find there is demand for it.

Most applications that we have implemented were relying heavily on data gathered from various tables by complex queries with varying constraints and joins which are built at runtime. Also as applications and data model change we needed something that gives us maximum security that when we change the model the application will still work - or the compiler should give us an error. This is why we tried to avoid using strings for column or table names completely - except for the model definition of course.
This has many times saved our lives and I really can't see how people could possibly survive with traditional OR-Mappers except for the simplest type of database activity.

Finally about the name:
This is a rather boring story. First, as we had the 'e' for our jsp-tag library originally taken from our company name "ESTEAM" we were looking for a name that also started with an ‘e’. Second it had to be a simple word as we couldn’t think of a suitable idiom. And finally since my kids have made me live in a parallel Star Wars universe for the last couple of years “Empire” was the closest match. We’re not looking to become as bad as the Galactic Empire though. So far we’re only just rebels in the universe of relational data persistence. But we’re determined to take on all these Hibernates and JPA implementations out there and maybe one day we will make the world a better place :-)

The two example applications provided with the core and the web-demo application provided with the struts extensions should give you a good idea about most of the functionality and how to apply it. However most people when starting to use Empire-db make things more complicated than necessary. So if you face any difficulties or think there must be a shorter easier way to achieve something don’t hesitate to ask.

On the other hand we are curious to hear what kind of solution you have implemented with Empire-db.
Best regards


Rainer


bachew wrote on Fr 30.01.2009 03:18
> Re: More history of Empire-db
>  
> Hi,
> The first entry in the FAQ answered part of my question -
> http://incubator.apache.org/empire-db/empiredb/faq.htm. But I would like to
> know more about the history of Empire-db, the people and the organization
> behind this interesting library. How it improves over the years and what
> kinda applications that Empire-db is written for. And erm... why name it
> Empire-db?
> 
> Hard to believe that someone finally did what I have in mind and this
> page<http://incubator.apache.org/empire-db/empiredb/hibernate.htm>explained
> what I always wanted to explain to people. I'm planning to write
> an application framework and it seems my only choice is Empire-db on
> database side, I wish to know more about it.
> 
> Thanks in advance.
>

re: More history of Empire-db

Posted by Rainer Döbele <do...@esteam.de>.
Hi bachew,

we’re glad to hear that you like Empire-db. We really believe it's the best thing since sliced bread and we hope more and more people will see the advantages.

About the history:
The basic idea, i.e. to describe the data model using classes and objects goes back to the middle of the 90's. At that time I was developing document management solutions under Windows using C++ and MFC. Back then I wrote the first attempt for a relational data persistence layer in C++. 

In 2000 me and my partner founded our company ESTEAM Software now focusing on developing Web-based applications in Java. For our first big project I used all the ideas from my C++ implementation to build a data persistence layer in Java. Since then we have used and improved the library (I don't want to use the word 'framework' in this context) in many fundamentally different applications such as CRM-tools, DataWarehouse utilities, Supply-Chain-Management etc. and for both Web and Rich-Client applications. Besides the Java implementation we also have a C# implementation; however we have not yet found the time to separate it from other stuff and make the necessary refactorings to match it with our Java Empire-db. We might do that I we find there is demand for it.

Most applications that we have implemented were relying heavily on data gathered from various tables by complex queries with varying constraints and joins which are built at runtime. Also as applications and data model change we needed something that gives us maximum security that when we change the model the application will still work - or the compiler should give us an error. This is why we tried to avoid using strings for column or table names completely - except for the model definition of course.
This has many times saved our lives and I really can't see how people could possibly survive with traditional OR-Mappers except for the simplest type of database activity.

Finally about the name:
This is a rather boring story. First, as we had the 'e' for our jsp-tag library originally taken from our company name "ESTEAM" we were looking for a name that also started with an ‘e’. Second it had to be a simple word as we couldn’t think of a suitable idiom. And finally since my kids have made me live in a parallel Star Wars universe for the last couple of years “Empire” was the closest match. We’re not looking to become as bad as the Galactic Empire though. So far we’re only just rebels in the universe of relational data persistence. But we’re determined to take on all these Hibernates and JPA implementations out there and maybe one day we will make the world a better place :-)

The two example applications provided with the core and the web-demo application provided with the struts extensions should give you a good idea about most of the functionality and how to apply it. However most people when starting to use Empire-db make things more complicated than necessary. So if you face any difficulties or think there must be a shorter easier way to achieve something don’t hesitate to ask.

On the other hand we are curious to hear what kind of solution you have implemented with Empire-db.
Best regards


Rainer


bachew wrote on Fr 30.01.2009 03:18
> Re: More history of Empire-db
>  
> Hi,
> The first entry in the FAQ answered part of my question -
> http://incubator.apache.org/empire-db/empiredb/faq.htm. But I would like to
> know more about the history of Empire-db, the people and the organization
> behind this interesting library. How it improves over the years and what
> kinda applications that Empire-db is written for. And erm... why name it
> Empire-db?
> 
> Hard to believe that someone finally did what I have in mind and this
> page<http://incubator.apache.org/empire-db/empiredb/hibernate.htm>explained
> what I always wanted to explain to people. I'm planning to write
> an application framework and it seems my only choice is Empire-db on
> database side, I wish to know more about it.
> 
> Thanks in advance.
>