9 deleted 4 characters in body
source | link

Compare this to the Pure-Java ORM Example or the Criteria Query Example - this is a ton of code, spread across multiplefour files! If you need the performance and the control, then invest the energy. But when ORM can save me from this, I think I'll let it.

Compare this to the Pure-Java ORM Example or the Criteria Query Example - this is a ton of code, spread across multiple files! If you need the performance and the control, then invest the energy. But when ORM can save me from this, I think I'll let it.

Compare this to the Pure-Java ORM Example or the Criteria Query Example - this is a ton of code, spread across four files! If you need the performance and the control, then invest the energy. But when ORM can save me from this, I think I'll let it.

8 Rewrote with multiple examples.
source | link

Debugging

I assume here that you have a tool that reliably generates your Java database objects for you.

With the Pure-Java example, there is no debugging of SQL or queries unless performance is an issue. You could still perform the wrong tests (e.g. forget to exclude ownerless things), but it's pretty straight-forward - keeps you focused on what you are doing, thus minimizing this possiblity. You can ask your ORM to spit out the actual queries in your log file if you need to tune them or see that you query the thing table 100 separate times or something like that, but this code results in a single query.

It's possible to pass the wrong type of object or nulls to the Criteria query. Also, since it's wordy, it takes longer to see what you are actually doing and bugs are easier to creep into your criteria.

With In-Java SQL, you have all the issues above, plus getting the SQL syntax right. I admit my symbols make this a little more complicated, but I feel the refactoring plus is bigger than the readability minus.

With the External SQL example, you have all of the error possibilities mentioned above, plus all the extra code from loading the results into the object. Plus the multiple files that can get out of synch. What if you rename, delete, or add a field - will you get a compilation error? Will you find all the places you need to change? Or do you have to find it in testing.

I'd have to say that from a debugging point of view, ORM with pure Java is a clear win, with additional debugging every step you move away from there.

Using ORM and symbols has saved me countless hours of refactoring difficulties and lets me make database changes with ease because when something breaks, it won't compile. When code gets big, refactoring is the only way to manage complexity, and it gets harder as it gets bigger, so above a certain size of code base, ease of refactoring becomes a primary goal. I'm not saying separate SQL makes it impossible to refactor

ORM also eliminates opportunities for bugs and the performance cost for this is usually minimal. Just offering one path You can still drop-down to relatively easy refactoringSQL as necessary, but I think having less SQL in your application is a better goal than putting SQL in separate files.

Using ORM and symbols has saved me countless hours of refactoring difficulties and lets me make database changes with ease because when something breaks, it won't compile. When code gets big, refactoring is the only way to manage complexity, and it gets harder as it gets bigger, so above a certain size of code base, ease of refactoring becomes a primary goal. I'm not saying separate SQL makes it impossible to refactor. Just offering one path to relatively easy refactoring.

Debugging

I assume here that you have a tool that reliably generates your Java database objects for you.

With the Pure-Java example, there is no debugging of SQL or queries unless performance is an issue. You could still perform the wrong tests (e.g. forget to exclude ownerless things), but it's pretty straight-forward - keeps you focused on what you are doing, thus minimizing this possiblity. You can ask your ORM to spit out the actual queries in your log file if you need to tune them or see that you query the thing table 100 separate times or something like that, but this code results in a single query.

It's possible to pass the wrong type of object or nulls to the Criteria query. Also, since it's wordy, it takes longer to see what you are actually doing and bugs are easier to creep into your criteria.

With In-Java SQL, you have all the issues above, plus getting the SQL syntax right. I admit my symbols make this a little more complicated, but I feel the refactoring plus is bigger than the readability minus.

With the External SQL example, you have all of the error possibilities mentioned above, plus all the extra code from loading the results into the object. Plus the multiple files that can get out of synch. What if you rename, delete, or add a field - will you get a compilation error? Will you find all the places you need to change? Or do you have to find it in testing.

I'd have to say that from a debugging point of view, ORM with pure Java is a clear win, with additional debugging every step you move away from there.

Using ORM and symbols has saved me countless hours of refactoring difficulties and lets me make database changes with ease because when something breaks, it won't compile. When code gets big, refactoring is the only way to manage complexity, and it gets harder as it gets bigger, so above a certain size of code base, ease of refactoring becomes a primary goal.

ORM also eliminates opportunities for bugs and the performance cost for this is usually minimal. You can still drop-down to SQL as necessary, but I think having less SQL in your application is a better goal than putting SQL in separate files.

7 Rewrote with multiple examples.
source | link

Criteria QueryIn-Java SQL Example

In a code which builds data forIf I had to drop down to SQL, e.g. to query thing IDs, it would look like the following. Please note that since symbol is a screen offinal String, the applicationconcatenation is done by the compiler, not at runtime, even in Java, even with the + operator:

Crit<Thing> tCritjdbcConn = CritHibernateUtil.creategetJdbcConnection(Thing.class); 
tCrit.add(Restrictions
String query = "select " + Thing.eq(SQL_id +
               " from " + Thing.HQL_company,SQL_thing someCompany));+
tCrit               " where " + Thing.add(RestrictionsSQL_company_id +
               " = ? and " + Thing.eq(SQL_is_deleted +
               " = b'0' and " + Thing.HQL_isDeleted,SQL_owner_id false)+
               " is not null";

PreparedStatement stmt = jdbcConn.prepareStatement(query);
tCritstmt.addsetLong(Restrictions1, someCompany.isNotNullgetId(Thing.HQL_owner));
List<Thing>
ResultSet thingListresults = tCritstmt.listexecuteQuery();

forwhile (Thingresults.next()) t{
 : thingList) { Long thingId = results.getLong(1));
    // do stuff with things IDs
}

In-Java SQL Example

Obviously, I try not to drop to SQL, unless I absolutely need to for performance reasons, or to do something like running a SQL report.

Criteria Query Example

If I had to drop down to SQL, e.g. to query thing IDs, it would look like the following. Please note that since everything isIn a symbol, the concatenation is done by the compiler, not at runtime, even in Java, even withcode which builds data for a screen of the + operatorapplication:

jdbcConnCrit<Thing> tCrit = HibernateUtilCrit.getJdbcConnectioncreate(Thing.class); 

String query = "select " + ThingtCrit.SQL_id +
               " from " + Thingadd(Restrictions.SQL_thing +
               " where " + eq(Thing.SQL_company_idHQL_company, +someCompany));
               " = ? and " + ThingtCrit.SQL_is_deleted +
               " = b'0' and " + add(Restrictions.eq(Thing.SQL_owner_id +
               " is not null";

PreparedStatement stmt =HQL_isDeleted, jdbcConn.prepareStatement(queryfalse));
stmttCrit.setLongadd(1, someCompanyRestrictions.getIdisNotNull(Thing.HQL_owner));

ResultSetfor results(Thing =t stmt.executeQuery();

while: (resultstCrit.nextlist()) {
    Long thingId = results.getLong(1));
    // do stuff with things IDs
}

Obviously, I somewhat try not to drop to SQLuse criteria, unless I absolutely need toexcept for performance reasons, or to do something like running a SQL report. I somewhat try not to use HQL, again Again, I want to stay in Java-land as much as possible.

Set<Thing> thingSet = someCompany.getThings();

for (Thing t : thingSetsomeCompany.getThings()) {
    if ( t.getIsDeleted() ||
         (t.getOwner() == null) ) {
        continue;
    }
    // do stuff with things
}

Clearly we are bringing back extra records (some ownerless and deleted Things), but if there are many Things and most are not deleted and have owners, the performance hit will be minimal.

Criteria Query Example

In a code which builds data for a screen of the application:

Crit<Thing> tCrit = Crit.create(Thing.class);
tCrit.add(Restrictions.eq(Thing.HQL_company, someCompany));
tCrit.add(Restrictions.eq(Thing.HQL_isDeleted, false));
tCrit.add(Restrictions.isNotNull(Thing.HQL_owner));
List<Thing> thingList = tCrit.list();

for (Thing t : thingList) {
    // do stuff with things
}

In-Java SQL Example

If I had to drop down to SQL, e.g. to query thing IDs, it would look like the following. Please note that since everything is a symbol, the concatenation is done by the compiler, not at runtime, even in Java, even with the + operator:

jdbcConn = HibernateUtil.getJdbcConnection(); 

String query = "select " + Thing.SQL_id +
               " from " + Thing.SQL_thing +
               " where " + Thing.SQL_company_id +
               " = ? and " + Thing.SQL_is_deleted +
               " = b'0' and " + Thing.SQL_owner_id +
               " is not null";

PreparedStatement stmt = jdbcConn.prepareStatement(query);
stmt.setLong(1, someCompany.getId());

ResultSet results = stmt.executeQuery();

while (results.next()) {
    Long thingId = results.getLong(1));
    // do stuff with things IDs
}

Obviously, I try not to drop to SQL, unless I absolutely need to for performance reasons, or to do something like running a SQL report. I somewhat try not to use HQL, again, I want to stay in Java-land as much as possible.

Set<Thing> thingSet = someCompany.getThings();

for (Thing t : thingSet) {
    if ( t.getIsDeleted() ||
         (t.getOwner() == null) ) {
        continue;
    }
    // do stuff with things
}

In-Java SQL Example

If I had to drop down to SQL, e.g. to query thing IDs, it would look like the following. Please note that since symbol is a final String, the concatenation is done by the compiler, not at runtime, even in Java, even with the + operator:

jdbcConn = HibernateUtil.getJdbcConnection(); 

String query = "select " + Thing.SQL_id +
               " from " + Thing.SQL_thing +
               " where " + Thing.SQL_company_id +
               " = ? and " + Thing.SQL_is_deleted +
               " = b'0' and " + Thing.SQL_owner_id +
               " is not null";

PreparedStatement stmt = jdbcConn.prepareStatement(query);
stmt.setLong(1, someCompany.getId());

ResultSet results = stmt.executeQuery();

while (results.next()) {
    Long thingId = results.getLong(1));
    // do stuff with things IDs
}

Obviously, I try not to drop to SQL, unless I absolutely need to for performance reasons, or to do something like running a SQL report.

Criteria Query Example

In a code which builds data for a screen of the application:

Crit<Thing> tCrit = Crit.create(Thing.class);
tCrit.add(Restrictions.eq(Thing.HQL_company, someCompany));
tCrit.add(Restrictions.eq(Thing.HQL_isDeleted, false));
tCrit.add(Restrictions.isNotNull(Thing.HQL_owner));

for (Thing t : tCrit.list()) {
    // do stuff with things
}

I somewhat try not to use criteria, except for performance. Again, I want to stay in Java-land as much as possible.

for (Thing t : someCompany.getThings()) {
    if ( t.getIsDeleted() ||
         (t.getOwner() == null) ) {
        continue;
    }
    // do stuff with things
}

Clearly we are bringing back extra records (some ownerless and deleted Things), but if there are many Things and most are not deleted and have owners, the performance hit will be minimal.

6 Rewrote with multiple examples.
source | link
5 added 3535 characters in body
source | link
4 added 543 characters in body
source | link
3 added 543 characters in body
source | link
2 added 312 characters in body
source | link
1
source | link