hibernate number save ?

[mark]

Is it possible to write a mapping for an entity so it can save any number
(Long, BigDecimal, int..) to one column in a table?
Can I do this

private Number number;

@Column(name="example")
public Number getNumber(){
return number;
}

??



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4482 (20091005) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Marcin Rze¼nicki]

Is it possible to write a mapping for an entity so it can save any number
(Long, BigDecimal, int..) to one column in a table?
Can I do this

private Number number;

@Column(name="example")
    public Number getNumber(){
         return number;
    }

??

Well, yes, you can implement your own type mapper in Hibernate, you'll
have to implement UserType interface and plug it in in configuration
file. I do not know if there is easier way though.

 

[markspace]

Is it possible to write a mapping for an entity so it can save any number
(Long, BigDecimal, int..) to one column in a table?

I don't actually use Hibernate, but I'm going to speculate:

1. You could store the number as a string. Use a varchar as the column
type.

2. You could serialize the object with XMLEncoder. These strings for
one object with one value are not large, usually less than 80
characters. Make a varchar(255) or similar and encode the object into
the database.

 

[Marcin Rze¼nicki]

I don't actually use Hibernate, but I'm going to speculate:

1.  You could store the number as a string.  Use a varchar as the column
type.

2.  You could serialize the object with XMLEncoder.  These strings for
one object with one value are not large, usually less than 80
characters.  Make a varchar(255) or similar and encode the object into
the database.

All that's not necessary. UserType is all he needs as I replied. The
question remains whether something simpler exists.

 

[markspace]

All that's not necessary. UserType is all he needs as I replied. The
question remains whether something simpler exists.

I didn't know what was required to set up his UserType. I took a swag
at something else.

 

[Marcin Rzeźnicki]

I didn't know what was required to set up his UserType.  I took a swag
at something else.

No, he isn't I think, but your method changes data representation and
I feel that it's too much mess. UserType is free of all these problems
so I'd generally prefer it.

 

[Lew]

One question mark suffices to indicate an interrogative. By convention,
multiple consecutive question marks (usually three, but other quantities also
work) represent astonishment, deep dubiety or aggressive cross-examination.

Well, yes, you can implement your own type mapper in Hibernate, you'll
have to implement UserType interface and plug it in in configuration
file. I do not know if there is easier way though.

Or he can relax his Java type requirement and use either BigDecimal or
BigInteger, than use Hibernate's "big_decimal" or "big_integer" types and
declare the database column NUMERIC. No need for a user type if a standard
one suffices.

Relaxing the requirement from Number makes sense anyway - part of the point of
entity attribute types is to make a good match for the data store types. so
some of the rules for maximum abstraction, minimum visibility, immutability
and the like don't apply. Entity classes serve a narrow purpose in JPA
frameworks like Hibernate and should not contain much behavior, too much
abstraction or other fooferol that would be natural in a more native Java
class. Entities should bridge the object-relational divide with clear, simple
getters and setters for concretely-implemented attributes, keeping a clear and
semantically valid mapping between data store types and Java types.

Where a table has a NUMERIC column, the closest Java match is
java.math.BigDecimal or java.math.BigInteger and the entity attribute should
be declared as such. Domain logic classes that use that entity are free to
assign that value to a Number variable, when they don't need more specific
knowledge.

 

[Marcin Rzeźnicki]

One question mark suffices to indicate an interrogative.  By convention,
multiple consecutive question marks (usually three, but other quantities also
work) represent astonishment, deep dubiety or aggressive cross-examination.


Or he can relax his Java type requirement and use either BigDecimal or
BigInteger, than use Hibernate's "big_decimal" or "big_integer" types and
declare the database column NUMERIC.  No need for a user type if a standard
one suffices.

He mentioned Number, yet ... (continued)

Relaxing the requirement from Number makes sense anyway - part of the point of
entity attribute types is to make a good match for the data store types. so
some of the rules for maximum abstraction, minimum visibility, immutability
and the like don't apply.  Entity classes serve a narrow purpose in JPA
frameworks like Hibernate and should not contain much behavior, too much
abstraction or other fooferol that would be natural in a more native Java
class.  Entities should bridge the object-relational divide with clear, simple
getters and setters for concretely-implemented attributes, keeping a clear and
semantically valid mapping between data store types and Java types.

.... you are right that it is strange to insist on Number `cause there
is no real counterpart on db side. Let's wait till we know more.