tags:

views:

292

answers:

3

Hi,

I would like to create myRecordSet object that extends java.sql.ResultSet and to implement a method that returns UTC date from SQL statement.

How can I extend from java.sql.ResultSet, I need an example.

10X

+3  A: 

Do not extend ResultSet. Create your entity class, let say Person. And implement 'get some date' method. Like so

class Person {
    public Person(ResultSet resultSet) {
       this.resultSet = resultSet;
    }

    ...
    public Date getBirthday() {
        resultSet.getDate("BIRTHDAY_COLUMN");
    }
    ...
}

You should be aware that this Person class is more like wrapper then pure entity. And using it is OK only in a scope where you have established connection and valid ResultSet object.

while (resultSet.next()) {
    Person person = new Person(resultSet);

    someAction(person);
    someMoreActions(person);
}

To make Person more entity-like you could consider using JPA

Mykola Golubyev
The entity class should be more like a bean, though, with its properties populated from the result set. In particular, it should allow for the ResultSet being closed after creating the entity. If the ResultSet needs to remain open (and pointed at the correct row) for the getters to work, you'll get into trouble.
Thilo
@Thilo: you are absolutely right. I should mention this. I just show how to replace ResultSet with custom class. And of course all the result set rules are valid for Person class.
Mykola Golubyev
I really wouldn't tight couple resultset with model.
BalusC
+1  A: 

I would like to create myRecordSet object that extends java.sql.ResultSet

Easy enough. A decent IDE will do it for you.

and to implement a method that returns UTC date from SQL statement.

Impossible, because you can't get your database to create an instance of your class instead of its own.

So you don't want to do that. What you really want to do is write a wrapper for ResultSet that talks to whatever you get from the database and adds whatever functionality you need. This is called the Delegate pattern.

EJP
+2  A: 

First, you don't extend interfaces, but you do implement interfaces :)

That said, you are likely looking in the wrong direction for the solution. Forget about implementing your ResultSet and just create a DAO class which does all the the ResultSet <--> Entity mapping tasks and do the desired date conversion just there. The DAO method may look like

public Person find(Long id) throws SQLException {
    Connection connection = null;
    PreparedStatement preparedStatement = null;
    ResultSet resultSet = null;
    Person person = null;

    try {
        connection = database.getConnection();
        preparedStatement = connection.prepareStatement(SQL_FIND);
        preparedStatement.setLong(1, id);
        resultSet = preparedStatement.executeQuery();
        if (resultSet.next()) {
            person = new Person();
            person.setId(resultSet.getLong("id"));
            person.setName(resultSet.getString("name"));
            person.setBirthDate(resultSet.getDate("birth_date"));
            // ...
        }
    } finally {
        close(connection, preparedStatement, resultSet);
    }

    return person;
}

You see, if the database column type is DATE, DATETIME or TIMESTAMP, then you can just use ResultSet#getDate() to obtain it as a java.util.Date object. To display the date in the desired format in the presentation layer, use the therefore supplied tools like SimpleDateFormat for "plain Java", fmt:formatDate for JSP pages, f:convertDateTime for JSF, etcetera.

Tight-coupling the ResultSet inside the model (entity, the "Person" in this example) is a bad idea. The model doesn't need to know anything about how it is been created and doing it may only potentially leak DB resources (because that approach may require the ResultSet to be open all the time) and may cause your app to crash sooner or later because the DB has run out of resources. Don't do that.

To get more ideas and insights about the DAO you may find this article useful.

BalusC
+1. "The model doesn't need to know anything about how it is been created". That is exactly why I am a little wary about systems like Hibernate that need to have a little tighter integration to support things like lazy-loading. All great when it works, but there is too much magic (supposedly) hidden under the hood that yet you still need to know about in order to use everything properly.
Thilo