Author: doebele
Date: Sun Mar 20 10:13:03 2022
New Revision: 1899080
URL: http://svn.apache.org/viewvc?rev=1899080&view=rev
Log: (empty)
Modified:
empire-db/site/pages/project.html
Modified: empire-db/site/pages/project.html
URL:
http://svn.apache.org/viewvc/empire-db/site/pages/project.html?rev=1899080&r1=1899079&r2=1899080&view=diff
==============================================================================
--- empire-db/site/pages/project.html (original)
+++ empire-db/site/pages/project.html Sun Mar 20 10:13:03 2022
@@ -141,8 +141,8 @@
and there are many available products
such as <a class="extern" target="_blank"
href="https://hibernate.org/";>Hibernate</a>, <a class="extern" target="_blank"
href="https://openjpa.apache.org/";>OpenJPA</a>, <a class="extern"
target="_blank" href="https://cayenne.apache.org/";>Cayenne</a> and <a
class="extern" target="_blank"
href="https://en.wikipedia.org/wiki/List_of_object%E2%80%93relational_mapping_software#Java";>more</a>.</p>
<p class="optional">But OR-Mapping has
many limitations by design. As it largely shields you from SQL, you have little
control over statements other than over the Where part of the query. On the
Java side you are largely limited to work with Entity objects rather than
specific query results in an "All or Nothing" manner.
- Maintaining Annotations or Mapping
files is a pain and requires special tools. For Relations you need to decide
between Lazy and Eager fetching which - no matter what you pick - will be good
sometimes and bad another. Metadata access is cumbersome and minimalistic.
- And the query APIs provided, are
unintuitive and largely limited to simple entity queries (with no control over
the "select" part) and struggling with ad hoc joins, subqueries and anything
that has to do with aggregation. Not to mention Union and Intersection queries.
In the Coding Horror blog Object-Relational Mapping has even been called the <a
class="extern" target="_blank"
href="https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/";
target="_blank">Vietnam of Computer Science</a>
+ Maintaining Annotations or Mapping
files is a pain and requires special tools. For Relations you need to decide
between Lazy and Eager fetching which - no matter what you pick - will be
sometimes good and sometimes bad. Metadata access is cumbersome and
minimalistic.
+ Furthermore, the query APIs provided
are unintuitive and largely limited to simple entity queries (with no control
over the "select" part) and they struggle with ad hoc joins, subqueries and
anything that has to do with aggregation. Not to mention Union and Intersection
queries. In the Coding Horror blog Object-Relational Mapping has even been
called the <a class="extern" target="_blank"
href="https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/";
target="_blank">Vietnam of Computer Science</a>
</p>
<p class="optional">Yes - in fairness -
modern ORMs have found ways to mitigate some of the conceptual shortcomings and
provide "workarounds", but this comes at a price. Just take a look at examples
for <a class="extern" target="_blank"
href="https://stackoverflow.com/questions/15990141/how-to-make-a-criteriabuilder-join-with-a-custom-on-condition";>getCriteriaBuilder()</a>
or <a class="extern" target="_blank"
href="https://mikekowdley.medium.com/hibernate-criteriaquery-fetching-a-partial-entity-and-child-with-joins-984987545dd2";>createTupleQuery()</a>
and it will make your head spin. Seriously JPA?</p>
@@ -153,10 +153,10 @@
<p><span class="bold">Empire-db</span>
however, is a different type of fish. It is not an OR-Mapper in the classical
sense, as it does not even attempt to rely on traditional Java Beans (POJOs)
for data interchange, yet providing equivalent features as ORMs do.
And it generally relies more on the
developer to actively do something rather than doing things automatically in
the background.</p>
- <p class="optional">Even though is
supports traditional Java Beans (POJOs), this is not the preferred approach.
Instead it provides Records which essentially are "Dynamic Beans" where you
have a generic getter / setter which takes the column as parameter.
+ <p class="optional">Even though it
supports traditional Java Beans (POJOs), this is not the preferred approach.
Instead it provides Records which essentially are "Dynamic Beans" where you
have a generic getter / setter which takes the column as parameter.
The record can be loaded as an entire
table row, or partially with selected columns or even combine fields from
different tables as a "logical" record.
- But the real advantage comes with the
ability not just to control all aspects of your SQL statements but also to do
that in a simple and intuitive way so that you are actually capable of using
everything a modern DBMS has to offer, such as various column functions, joins
of any type (inner, outer, cross) with any kind of join restriction, joins on
subqueries, aggregation, and so on,
- and all that without having to fall
back to SQL in String literals or the need for getting a special University
degree.</p>
+ But the real advantage comes with the
ability not just to control all aspects of your SQL statements, but also to do
that in a simple and intuitive way so that you are actually capable of using
everything a modern DBMS has to offer, such as various column functions, joins
of any type (inner, outer, cross) with any kind of join restriction, joins on
subqueries, aggregation, and so on.
+ All that without having to fall back to
SQL in String literals or the need for getting a special University degree.</p>
<p class="optional">The advantage
becomes especially apparent in scenarios with large data models, complex
relations, sophisticated query demands. And this is also where metadata becomes
as - or sometimes even more - important than the actual data itself. With
Metadata you can achieve so much, from writing generic functions to building or
improving user interfaces.
<!--
@@ -178,7 +178,7 @@
<h1>Can your ORM do that?</h1>
- <p>Compare what your current data persistence solution
with what Empire-db has to offer.</p>
+ <p>Compare your current data persistence solution with
what Empire-db has to offer.</p>
<h3>Building queries</h3>
<p>The query building engine is the heart of Empire-db.
Empire-db can build DQL, DML and DDL statements in the "flavour" of the DBMS
used.</p>
@@ -663,9 +663,9 @@ log.<span class="func">info</span>(<span
<div class="content">
<h1>Final word</h1>
<p>In software development things get complicated.
Sometimes sooner, sometimes later, but they inevitably do.<br/>
- What was once meant to be a "Simple Database", may well
turn into a Monster over the years, with ever more tables, views, columns,
data.</p>
+ What was once meant to be a "Simple Database", may well
turn into a monster over the years, with ever more tables, views, columns,
data.</p>
- <p>So how do you tame the Monster?</p>
+ <p>So how do you tame the monster?</p>
<p>We believe the key to that are Simplicity and
Flexibility.</p>
<ul class="bullets">
