Java – Hibernate.INTEGER is unavailable, when the Hibernate version is upgraded to 4.2.0.CR1

compiler-errorshibernatejavaoracle

I have just upgraded Hibernate from 3.2.5 to 4.2.0.CR1. I was using something like the following methods in DAO classes to locate the current row number in Oracle 10g with the createSQLQuery() method.

SELECT row_num
FROM   (SELECT row_number()
                 OVER (
                   ORDER BY banner_id DESC) AS row_num,
               banner_id
        FROM   banner_images
        ORDER  BY banner_id DESC)
WHERE  banner_id = :id

@Override
@SuppressWarnings("unchecked")    
public int getCurrentRow(String id, int rowsPerPage)
{        
    return (Integer) sessionFactory
                    .getCurrentSession()
                    .createSQLQuery("Above query")
                    .addScalar("row_num", Hibernate.INTEGER)  //<------- ???
                    .setParameter("id", Long.parseLong(id))
                    .uniqueResult();
}

The .addScalar("row_num", Hibernate.INTEGER) method as shown in the above code snippet, issues a compile-time error.

cannot find symbol
symbol:   variable INTEGER
location: class Hibernate

It is not available in the org.hibernate.Hibernate class. The NetBeans IDE I'm using is 7.2.1 is not listing such a constant. Google search couldn't lead me to the actual solution. So what is the alternative in this version of Hibernate (4.2.0.CR1)?

Best Answer

This Hinernate.Integer is deprecated since 3.6.x

You should use IntegerType.INSTANCE instead.

Related Solutions

Java – How to tell Maven to use the latest version of a dependency

NOTE:

The mentioned LATEST and RELEASE metaversions have been dropped for plugin dependencies in Maven 3 "for the sake of reproducible builds", over 6 years ago. (They still work perfectly fine for regular dependencies.) For plugin dependencies please refer to this Maven 3 compliant solution.

If you always want to use the newest version, Maven has two keywords you can use as an alternative to version ranges. You should use these options with care as you are no longer in control of the plugins/dependencies you are using.

When you depend on a plugin or a dependency, you can use the a version value of LATEST or RELEASE. LATEST refers to the latest released or snapshot version of a particular artifact, the most recently deployed artifact in a particular repository. RELEASE refers to the last non-snapshot release in the repository. In general, it is not a best practice to design software which depends on a non-specific version of an artifact. If you are developing software, you might want to use RELEASE or LATEST as a convenience so that you don't have to update version numbers when a new release of a third-party library is released. When you release software, you should always make sure that your project depends on specific versions to reduce the chances of your build or your project being affected by a software release not under your control. Use LATEST and RELEASE with caution, if at all.

See the POM Syntax section of the Maven book for more details. Or see this doc on Dependency Version Ranges, where:

A square bracket ( [ & ] ) means "closed" (inclusive).
A parenthesis ( ( & ) ) means "open" (exclusive).

Here's an example illustrating the various options. In the Maven repository, com.foo:my-foo has the following metadata:

<?xml version="1.0" encoding="UTF-8"?><metadata>
  <groupId>com.foo</groupId>
  <artifactId>my-foo</artifactId>
  <version>2.0.0</version>
  <versioning>
    <release>1.1.1</release>
    <versions>
      <version>1.0</version>
      <version>1.0.1</version>
      <version>1.1</version>
      <version>1.1.1</version>
      <version>2.0.0</version>
    </versions>
    <lastUpdated>20090722140000</lastUpdated>
  </versioning>
</metadata>

If a dependency on that artifact is required, you have the following options (other version ranges can be specified of course, just showing the relevant ones here):

Declare an exact version (will always resolve to 1.0.1):

<version>[1.0.1]</version>

Declare an explicit version (will always resolve to 1.0.1 unless a collision occurs, when Maven will select a matching version):

<version>1.0.1</version>

Declare a version range for all 1.x (will currently resolve to 1.1.1):

<version>[1.0.0,2.0.0)</version>

Declare an open-ended version range (will resolve to 2.0.0):

<version>[1.0.0,)</version>

Declare the version as LATEST (will resolve to 2.0.0) (removed from maven 3.x)

<version>LATEST</version>

Declare the version as RELEASE (will resolve to 1.1.1) (removed from maven 3.x):

<version>RELEASE</version>

Note that by default your own deployments will update the "latest" entry in the Maven metadata, but to update the "release" entry, you need to activate the "release-profile" from the Maven super POM. You can do this with either "-Prelease-profile" or "-DperformRelease=true"

It's worth emphasising that any approach that allows Maven to pick the dependency versions (LATEST, RELEASE, and version ranges) can leave you open to build time issues, as later versions can have different behaviour (for example the dependency plugin has previously switched a default value from true to false, with confusing results).

It is therefore generally a good idea to define exact versions in releases. As Tim's answer points out, the maven-versions-plugin is a handy tool for updating dependency versions, particularly the versions:use-latest-versions and versions:use-latest-releases goals.

Java – What are the possible values of the Hibernate hbm2ddl.auto configuration and what do they do

From the community documentation:

hibernate.hbm2ddl.auto Automatically validates or exports schema DDL to the database when the SessionFactory is created. With create-drop, the database schema will be dropped when the SessionFactory is closed explicitly.

e.g. validate | update | create | create-drop

So the list of possible options are,

validate: validate the schema, makes no changes to the database.
update: update the schema.
create: creates the schema, destroying previous data.
create-drop: drop the schema when the SessionFactory is closed explicitly, typically when the application is stopped.
none: does nothing with the schema, makes no changes to the database

These options seem intended to be developers tools and not to facilitate any production level databases, you may want to have a look at the following question; Hibernate: hbm2ddl.auto=update in production?

Best Answer

Related Solutions

Java – How to tell Maven to use the latest version of a dependency

Java – What are the possible values of the Hibernate hbm2ddl.auto configuration and what do they do

Related Topic