brettwooldridge / sansorm Goto Github PK

java.sql.Timestamp is instance of java.util.Date.
The code below (in OrmBase.mapSqlType) truncates Timestamp precision to milliseconds

  case Types.TIMESTAMP:
     if (object instanceof java.util.Date) {
        return new Timestamp(((java.util.Date) object).getTime());  // << microseconds are lost if object is already a Timestamp
     }
     break;

Simple solution:

  case Types.TIMESTAMP:
     if (object instanceof Timestamp) {
        return object;
     }
     if (object instanceof java.util.Date) {
        return new Timestamp(((java.util.Date) object).getTime());
     }
     break;

It seems pretty simple to add H2's merge function to OrmWriter, but it's a right pain to add it externally.

Is there a reason why it's absent at the minute?

I am wondering if there is any way JPA dependency can be avoided and instead resultset can be directly mapped to POJO just like Spring JDBC template. In my opinion it'll be one less dependency to worry about.

For entity classes whose Id fields also have a Converter attribute, the behaviour of SansOrm is buggy (or at least inconsitent):

• When persisting an entity, e.g. via OrmElf->OrmWriter.writeObject(), the actual id value written to the database is determined via Introspected.get(target, FieldColumnInfo), which, as expected, applies the AttributeConverter.toDatabaseColumn() (or Enum conversion).
• When requesting that entity using OrmElf->OrmReader.getObjectById(), using (ofcourse) the "java-side" id value of the entity, it won't be found, since getObjectById() just uses the given value as bind parameter, without applying the appropriate toDatabaseColumn() converter first.

For OrmReader.getObjectById() specific, a quick and dirty fix could be:

   ...

   public static <T> T objectById(final Connection connection, final Class<T> clazz, final Object... args) throws SQLException
   {
      String where = getWhereIdClause(Introspector.getIntrospected(clazz), args);
      return objectFromClause(connection, clazz, where, args);
   }

   ...

   private static String getWhereIdClause(Introspected introspected, final Object... args) {
      final StringBuilder where = new StringBuilder();
      List<FieldColumnInfo> idFcInfos = introspected.getIdFcInfos();
      int i = 0;
      for (FieldColumnInfo fcInfo : idFcInfos) {
         where.append(fcInfo.getColumnName()).append("=? AND ");
         if (i < args.length) {
            // Maybe need to convert the argument, using same logic as Introspected.get()
            // Note: modifying the given args array!
            if (fcInfo.getConverter() != null) {
               args[i] = fcInfo.getConverter().convertToDatabaseColumn(args[i]);
            } else if (fcInfo.enumConstants != null && args[i] != null) {
               args[i] = (fcInfo.enumType == EnumType.ORDINAL ? ((Enum<?>) args[i]).ordinal() : ((Enum<?>) args[i]).name());
            }
         }
         i++;
      }
      // the where clause can be length of zero if we are loading an object that is presumed to
      // be the only row in the table and therefore has no id.
      if (where.length() > 0) {
      ...

However:

• The same issue also pops up in other places, for example in OrmWriter (setParamsExecute, deleteObject, updateObject), or maybe Introspected.getActualIds, so a more structural solution seems appropriate.
• It would more or less duplicate existing conversion code currently in Introspected.get; maybe it's better to create a conversion function in that class.

Any ideas on this?

I notice that 3.7 has appropriate OSGi bundle headers, but with the heavy use of static members and thread locals, I'm wondering if the library has been tested in an OSGi container and what the circumstances of the testing was?

SansOrm supports decorating a field w/ @convert to help conversion from Java types to JDBC types, but this is not really documented.

Brett, I really liked SansORM. Wondering if you have any performance benchmark comparing this against just plain old JDBC?

When trying to map a query to a "POJO", if the query returns a column non existent in the POJO classe, we get a NullPointerException.
Could / Should this be treated and those column ignored in the mapping?

@sergiorussia I have a favor to ask. I want you to break our API. 😄

As SansORM has evolved over time, some minor inconsistencies have crept in; due to expendiency as well as lack of clarity about the separation of concerns (I'm guilty on both counts).

Because master already contains breaking changes (the removal of deprecated methods), the next release needs to go out as v3.x.x. So, now is the perfect time to make unnecessary work for myself ... er ... the perfect time to move things around.

Background

As originally conceived, OrmElf was to contain methods that deal in the currency of "objects" (/classes), but know nothing of where Connection, Statement, or ResultSet objects come from. For example:

public static <T> T resultSetToObject(ResultSet resultSet, T target) throws SQLException

public static <T> List<T> listFromClause(Connection connection, Class<T> clazz, String clause, Object... args) throws SQLException
...

Whereas SqlClosureElf knows how to acquire connections (using SqlClosure), and in addition to "object" convenience methods, might also contain pure SQL convenience methods.

Inconsistencies

Unfortunately, some pure SQL functionality has crept into OrmElf, and I would like to see it moved to SqlClosureElf. The ones I have identified are these:

public static String getInClausePlaceholders(final String...items)

public static ResultSet executeQuery(Connection connection, String sql, Object... args) throws SQLException

public static int executeUpdate(Connection connection, String sql, Object... args) throws SQLException

public static Number numberFromSql(Connection connection, String sql, Object... args) throws SQLException

Do you feel like refactoring those?

This is probably just a stupid question, but here we go:

At the end of the public final T execute() method of SqlClosure the finally clause within the finally (line 227) applies for all connections, regardless of the value of txOwner.
I.e. a connection is closed, even when an external TransactionManager is present.
Is that intendet?

Hi writer
Can your project resolve my question?
JOIN QUERY always produce a new resultSet, and i always must new a entity that receive it. that's let me down, i dont know if your project can handle this.

Hello,

I was planning on using this library but then stumbled upon:

src/main/java/com/zaxxer/sansorm/internal/Introspector.java which has this copyright header:

/*
 * The contents of this file are proprietary and may not be
 * modified or distributed in source or compiled form without
 * express written permission from the copyright holders.
 *
 * Copyright 2008-2011, DancerNetworks
 * All rights reserved.
 */

Everything else seems to be Apache 2.

Hello, is there any reason why BigDecimal is not converted to Double if fieldType == Double.class?

Right now, for CRUD operations, database table name is evaluated in this method:

Is the a reason why this method does not default to clazz.getSimpleName() when there is no @Table annotation?

We use a sybase database with uppercase table and column names.

In Introspected#processColumnAnnotation the FieldColumnInfo.columnName is lower cased from the @column annotation. This leads to errors with the SQL statements generated by SqlClosureElf. (changing the behavior of sybase requires a global modification of sorting on the sybase server and is not an option.)

Is the toLowerCase() required for column names or can this be changed - in gereral or with a configurable default behavior?

Besides getting the column name from field name is not consistent.
If the field has a @column annotation without name attribute, the field name is accepted as is. (line 475)
If the field has no annotation the field name will be lower cased. (line 501)

Hi
i can't find different with Mybatis
maybe you can teach me

Hello.
Thanks for your impressive work.

I would like to try your library.
Mostly its ability to map ResultSet to object in conjunction with gorgeus SqlObject API of another SQL library, JDBI (unfortunately, it has very poor object mapping capabilities).

But unfortunately I cannot find it in any central repos. Even beta or alpha version. Please publish your library in maven repos, it will make installation process easier and will certainly boost library's popularity.

P.S. Sorry for my english.

JDBC doesn't support Named parameter in SQL natively. However some of the leading libraries do support this. Also it makes SQL much more readable. Something similar to Spring JDBC template:

http://docs.spring.io/spring/docs/2.5.x/reference/jdbc.html#jdbc-NamedParameterJdbcTemplate

Would be nice addition.

Is this still a problem with the MySQL JDBC driver v8 ?
I tried some basic examples and it seemed to work quite well.