[Hibernate-JIRA] Commented: (HHH-1936) IdentityGenerator doesn't support BigInteger as a valid identity type.
by Julien Kronegg (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1936?page=c... ]
Julien Kronegg commented on HHH-1936:
-------------------------------------
The proposed file IdentifierGeneratorFactory.java (# 14444 ) would not work for very high value because of this code snippet:
else if ( clazz==BigDecimal.class ) {
return new BigDecimal( rs.getLong(1) );
}
If the database table primary key is a DECIMAL(21) or longer, (silent) overflow will occur since the max value is 10^21-1 for DECIMAL(21) and Long has a max value of 2^63-1, which is lower than 10^21-1.
You would use rs.getBigDecimal(1) instead of new BigDecimal( rs.getLong(1) )
The same would probably occur for the following code snippet:
else if ( clazz==BigInteger.class ) {
return new BigInteger( "" + rs.getInt(1) );
}
> IdentityGenerator doesn't support BigInteger as a valid identity type.
> ----------------------------------------------------------------------
>
> Key: HHH-1936
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1936
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5, Sybase 12.05, Window/ Unix
> Reporter: Leonid Shtivelman
> Attachments: IdentifierGeneratorFactory.java
>
>
> Identity generator strategy doesn't support BigInteger as a valid id type. This causes problem with Sybase which requires identity column to be numeric. It would seem an obvious way to get around this problem is to set column mapping to long in hibernate xml and the actual java object. This will solve obvious problem of creating identity, but will cause performance problem on selection. In order for Sybase to use index for parameter query the variable type of the parameter and column index type has to be the same. If ones maps column type to Long, Hibernate will use JDBC method setLong(long) to set value in the prepared statement. This will cause mismatch between parameter type and column index type, and Sybase will not use index to locate index. As you can see this is a big problem for anyone that is using identity columns Sybase and Hibernate
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[Hibernate-JIRA] Created: (HHH-3816) Map joins as XML in a column
by Paul Murray (JIRA)
Map joins as XML in a column
----------------------------
Key: HHH-3816
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3816
Project: Hibernate Core
Issue Type: New Feature
Components: core
Affects Versions: 3.3.1
Reporter: Paul Murray
We are working with a hibernate-centric relational model written by a third party (ie: the database schema is generated from hibernate). It uses a lot of subclasses and one-to-many buckets, where the items in the buckets are essentailly beans. Hibernate persists this as a database schema with hundreds of tables. Great for hibernate, but lousy to write SQL against.
XML does a great job of handling data items that are buckets of other data items, and data itens that are just beans. However, it's lousy at doing relational data - many-to-many associations.
What I would like in hibernate is an ability to say that a one-to-many collection of beans is to be stored as serialised XML in a column (a varchar or CLOB). That is, a new strategy in addition to the ones mentioned here http://www.hibernate.org/346.html . I'd like to be able to specify the xml document type, schema, namespace and so on to be stored in that xml, so that the resulting column contains a complete, valid document. It would even be nice if hibernate could generate the xml schema, so that I can validate input.
If items in that collection contain relational links that are not embedded xml, then it might be nice if the link (which hibernate needs to be able to understand when it is pulling the data into memory as beans) somehow conforms to XPath. Of course, the easy way to manage this is that hibernate can simply refuse to do it.
Perhaps, in addition to collections, one might be able to sepcify that a group of fields (including collections etc) are all stored in a single database column containing XML. Thus, an ADDRESS table might have an address_id and status stored as database fields, but the address contents - street number etc etc - could all be jammed into a single XML chunk in a CLOB column named "address stuff".
This means that my actual logical relational entities get stored as relational tables, which is what an RDBMS is good at; but the reams and reams of sub and sub-sub-sub detail records get put in XML, which is what XML is good at.
* I get a small(er) number of tables
* my database is not cluttered with a load of specific little tables holding unintersting collections
* the structure of the data stored in detail-type items can be extended without database schema changes
* the identifiable nuggets of user-editable data can be associated with stylesheets to convert them to html, and xforms for editing them
* there's a clear separation of stuff that embodies the logical structure of the data from stuff that's content data
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[Hibernate-JIRA] Created: (HHH-3814) BatchUpdateException is thrown too late (i.e., when adding unrelated objects) when violating constraints, leading to incorrect stack trace
by Daniel Schreiber (JIRA)
BatchUpdateException is thrown too late (i.e., when adding unrelated objects) when violating constraints, leading to incorrect stack trace
------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3814
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3814
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Tested using Hibernate 3.3.1.GA, HSQLDB 1.8.0.7 and also Oracle 9i.
Reporter: Daniel Schreiber
Attachments: hibernate-bug.zip
When adding objects to a stateless session, a BatchUpdateException is thrown when the objects being added violate a UNIQUE constraint. Hower, the exception is thrown "too late": It is NOT thrown when adding an object that violates a constraint, but only when an object of a different type is added.
It seems that Hibernate doesn't check constraints each time an object is added to the session, but only if the type being added changes; I presume this is some kind of optimization. This leads to confusion when debugging, because the statement that causes the exception is not actually the real cause.
I have attached a minimal example demonstrating the issue using HSQLDB. The project can be built using maven.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months