You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@empire-db.apache.org by do...@apache.org on 2022/03/20 10:13:03 UTC

svn commit: r1899080 - /empire-db/site/pages/project.html

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">