«

Hi hibernate guys,

I am facing a problem with data type problem in hibernate mapping.
Below is a standard example from hibernate.org. It works perfectly
fine.

public class Person {

private Long id;
private int age;
private String firstname;
private String lastname;

Person() {}

// Accessor methods for all properties, private setter for 'id'

}


<hibernate-mapping>

<class name="Person" table="PERSON">
<id name="id" column="PERSON_ID">
<generator class="increment"/>
</id>
<property name="age"/>
<property name="firstname"/>
<property name="lastname"/>
</class>

</hibernate-mapping>



In my case data type of id is int.
In database also it is int. I am using MSSQL server and hibernate3.0
I am getting an exception like
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Value
can not be converted to requested type

Is there any other way?

<> schrieb im Newsbeitrag
news: ups.com...
> <hibernate-mapping>
[snip]
>
> <class name="Person" table="PERSON">
> <id name="id" column="PERSON_ID">
> <generator class="increment"/>
> </id>
[snip]
> In my case data type of id is int.
> In database also it is int. I am using MSSQL server and hibernate3.0
> I am getting an exception like
> java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Value
> can not be converted to requested type
>
> Is there any other way?

You should use long or better Long as the type for your id. The database
type int my have another domain than the Java int and may be mapped to long
by Hibernate. Note that in the example above there is no type defined. So
Hibernate derives the type of your POJO property from the database what
probably leads to long instead of int.
Nevertheless your int id should work, if you define id like

<id name="id" column="PERSON_ID" type="int">
<generator class="increment"/>
</id>

Regards
Sebastian

Are you using the official sql server driver? Its unsupported in their
FAQ.

http://www.hibernate.org/120.html

You may have better luck with one of the commerical or open source
drivers available.

I can't answer your question specifically, but you may have some luck
on the tools forum:

http://forum.hibernate.org/viewforum.php?f=6

There was just new tools release, alpha 5. You may try that.

HTH,
iksrazal
http://www.braziloutsource.com/

On 25 Aug 2005 07:24:32 -0700, wrote or quoted :

> private Long id;
> private int age;

There is something puzzling about that example. You have an Object
Long but a primitive int. I would think Hibernate/the database would
demand one way or the other.

I have long advocated that you should be able to access SQL with an
iterator of custom objects for the result set. It looks as if
Hibernate is doing that. Am I correct?

Does Hibernate generate XML from a class description? Does it do the
reverse? Does it generate SQL queries? Does it turn SQL queries into
XML or Class descriptions?

Usually there is a ton of detailed documentation, but very little
overview documentation that answer the "obvious" questions you need to
know to have a clue what a tool is for. I try to fill in that gap
with the Java glossary entries.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

"Roedy Green" <look-> wrote:
>
>
> I have long advocated that you should be able to access SQL with an
> iterator of custom objects for the result set. It looks as if
> Hibernate is doing that. Am I correct?
>
> Does Hibernate generate XML from a class description? Does it do the
> reverse? Does it generate SQL queries? Does it turn SQL queries into
> XML or Class descriptions?
>
> Usually there is a ton of detailed documentation, but very little
> overview documentation that answer the "obvious" questions you need to
> know to have a clue what a tool is for. I try to fill in that gap
> with the Java glossary entries.
>

Hibernate is an Object/Relational Mapper.

Conceptually, you have entities in the database, and objects in memory.
Objects map to rows in tables. Properties of those objects map to columns of
the row. Conceptually, you start a (Hibernate) transaction, fish one or more
POJOs out of the database (somehow), do stuff with them (that might change
their state) and commit the Hibernate transaction. Hibernate translates the
state modifications in the POJOs into the correct SQL DML to write the
changes back to the database.

Yes, you can iterate a SQL query with POJOs. It's not the first use-case
that Hibernate attempts to solve, but it is in there. You need to be aware
of what the mapping between the database world and the POJO world is,
though: it won't generate classes on the fly.

There is an experimental feature that does not require the memory
representation to be POJOs, but can be a DOM4J DOM instance instead. Or just
a tree of Map instances.

I don't think there's a straightforward way to generate the DOM from the
POJOs, or POJOs from the DOM without going to the database first, but that
seems like it's an obvious extension... the mapping document can be
one-and-the-same.

On Sat, 27 Aug 2005 17:11:38 -0700, "Adam Maass"
<> wrote or quoted :

>Conceptually, you have entities in the database, and objects in memory.
>Objects map to rows in tables. Properties of those objects map to columns of
>the row. Conceptually, you start a (Hibernate) transaction, fish one or more
>POJOs out of the database (somehow), do stuff with them (that might change
>their state) and commit the Hibernate transaction. Hibernate translates the
>state modifications in the POJOs into the correct SQL DML to write the
>changes back to the database.

Is Hibernate a server side only beast or do you typically ship these
POJQs over the wire to Applets, and send only the changes back?

This is similar to what I faked in Java 1.0 with Symantec dbAnywhere.
I am glad to see the idea catching on. I went a step further
integrating the GUI object with the database object, so that on commit
all "smart" GUI objects whose values had changed triggered an SQL
update.

There is a lot of pointless overhead going on that could be bypassed
if Hibernate talked directly to the database engine, bypassing SQL.
Perhaps some day there will be Hibernate bypass into the engine.
Ideally the database would deliver binary format records that could be
instantly converted to Objects. The list of changes could be stream of
binary field numbers.



--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

"Roedy Green" <look-> wrote:
> On Sat, 27 Aug 2005 17:11:38 -0700, "Adam Maass"
> <> wrote or quoted :
>
>>Conceptually, you have entities in the database, and objects in memory.
>>Objects map to rows in tables. Properties of those objects map to columns
>>of
>>the row. Conceptually, you start a (Hibernate) transaction, fish one or
>>more
>>POJOs out of the database (somehow), do stuff with them (that might change
>>their state) and commit the Hibernate transaction. Hibernate translates
>>the
>>state modifications in the POJOs into the correct SQL DML to write the
>>changes back to the database.
>
> Is Hibernate a server side only beast or do you typically ship these
> POJQs over the wire to Applets, and send only the changes back?
>

The POJOs can be "detached" from the Hibernate session in which they
originate, and provided they all implement Serializable, can be shipped to a
client which makes the changes, then serialized back to the server, where
they can be re-attached to another Hibernate session; the second session
then makes the updates.

There are some tricky bits to this: some of the semantics that Hibernate
guarantees while you're operating in the context of a single session aren't
true any more. And Hibernate expends a fair amount of effort to enable lazy
fetching from the database; you can't fetch lazily from the database if the
objects have already been detached... you have to know the extent of the
object graph you want to send and ensure that it has all been fetched before
detachment.

>
> There is a lot of pointless overhead going on that could be bypassed
> if Hibernate talked directly to the database engine, bypassing SQL.
> Perhaps some day there will be Hibernate bypass into the engine.
> Ideally the database would deliver binary format records that could be
> instantly converted to Objects. The list of changes could be stream of
> binary field numbers.
>

This has been tried before. They were called object databases.

IMO, object databases were brilliant technology that were dead before they
arrived; the RDBMSs have too much entrenched technology, query performance,
secondary tools, and just general industry know-how to have much of a
competitive threat from OODBMSs. The purchasing manager's thinking goes
something like this: OODBMSs don't buy you all that much more than RDBMSs,
and you give up an awful lot to get there. So why should he take the risk?

[lars.egarots]

Sometimes its hard and tedious to get the mapping correct. I like to use this tool to have it done automatically: http://www.javatosql.com

It analyzes my Java objects and creates the sql and hibernate config files.