[Hibernate-JIRA] Created: (HHH-2434) No standard way to calculate date intervals in HQL
by Don Smith (JIRA)
No standard way to calculate date intervals in HQL
--------------------------------------------------
Key: HHH-2434
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2434
Project: Hibernate3
Type: Improvement
Components: core
Versions: 3.2.0.ga
Environment: All
Reporter: Don Smith
Priority: Minor
Date interval calculation is supported differently on different database platforms. Some allow direct arithmetic on columns, i.e. enddate - startdate. Some require functions, datediff(), timestampdiff(), etc. This causes cross-platform issues. For instance, an application I work on has to figure out the dialect that's in use (out of the four we currently support) and create the HQL string differently for each platform. This is undesirable, since we use Hibernate to enable platform neutrality; our installer asks which database the customer wants to deploy to, and sets the dialect. We'd like our codebase to be free of dialect-specific code.
I propose a standard solution for this, either direct date arithmetic, or a function defintion that is ported across dialects. Timestampdiff seems to be a fairly standard function, although DB2 has different syntax than MySQL and Derby. I've seen hints that timestampdiff is part of the ANSI SQL standard, but do not have access to the documents to determine if that is the case.
--
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
12 years, 9 months
[Hibernate-JIRA] Created: (HHH-3348) loading context
by benjamin Leroux (JIRA)
loading context
---------------
Key: HHH-3348
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3348
Project: Hibernate3
Issue Type: New Feature
Affects Versions: 4.x
Reporter: benjamin Leroux
Priority: Minor
this proposal is for creating a loading context into hibernate
Let me explain:
On an application, we often hesitating between the two major strategies of loading (eager or lazy). But for some reason there has no good choice. In fact, it depends on the context.
So we do lazy loading and redefine some method with new request with some "join". In fact, it lead to complexity and decrease managability of the application.
So my idea is to allow the definition of a context (like transactional context) where we we can put the loading strategie to adopt.
with annotation it could be very easy to define such context. Let see this exemple :
Avec les annotations, cela pourrait conduire à une ecriture de ce style :
@LoadingStrategie (type=eager from="Car" get={"driver"})
public List<Car> getAllCarForDriving(){
// Some fonctions
}
@LoadingStrategie (type=eager from="Car" get={"driver","passengers"})
public List<Car> getAllCarForTravelling(){
// Some fonctions
}
In the method getAllCarForDriving when we call a hql request on car it automaticaly get driver but in the method getAllCarForTravelling passengers and the driver is loaded.
--
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
12 years, 9 months
[Hibernate-JIRA] Created: (HHH-5184) Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode
by Steve Ebersole (JIRA)
Create a ConnectionAcquisitionMode as corollary to ConnectionReleaseMode
------------------------------------------------------------------------
Key: HHH-5184
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5184
Project: Hibernate Core
Issue Type: Improvement
Reporter: Steve Ebersole
Fix For: 3.6
Originally ConnectionReleaseMode was added to work around a particular problem of connection "leaking" by JTA containers when used in situations of nested session EJB calls. The connection was not really leaked, but it would appear that way to the JTA resource tracker.
The situation was:
{code}
class EJB1 {
public void doSomething() {
Session s = getCurrentSession();
...
ejb2.doSomethingElse();
// now use the HIbernate session
}
}
class EJB2 {
public void doSomethingElse() {
Session s = getCurrentSession();
// Use the session in a way that requires a Connection...
}
}
{code}
What happens is that EJB1 obtains a Session reference. Just getting a Hibernate Session does not make it get a Connection; the Session delays getting a Connection until it actually needs one. EJB1 then makes the call into EJB2. Again, EJB2 obtains the same Session reference and does some work, so the Session obtains a Connection. Historically that Connection would be held until the Session closed. However that was problematic in this scenario above; to the JTA container it looks like EJB2.doSomethingElse() is leaking the connection outside the transaction boundary (this was many years ago and AFAIU many of these JTA scoping routines have become more sophisticated).
At the time we decided to add the idea of Connection "releasing". However constantly releasing and re-obtaining the Connection can affect performance. Another solution to the problem above is to obtain the Connection up front instead.
So initially I see:
ConnectionAcquisitionMode.AS_NEEDED
ConnectionAcquisitionMode.IMMEDIATELY
--
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
12 years, 9 months
[Hibernate-JIRA] Created: (HHH-3512) Registration of IdentifierGenerators (short naming)
by Steve Ebersole (JIRA)
Registration of IdentifierGenerators (short naming)
---------------------------------------------------
Key: HHH-3512
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3512
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.4, 4.x
Another way to look at this is to allow configuration of IdentifierGeneratorFactory.
Either allow explicit registration under a short name in config:
<identifier-generator name="sequence-style" class="org.hibernate.id.enhanced.SequenceStyleGenerator"/>
or via an explicit contract:
public interface Registerable {
public String getRegistrationName();
}
public class SequenceStyleGenerator implements IdentifierGenerator, Registerable {
...
public String getRegistrationName() {
return "sequence-style";
}
}
The second, while certainly more verbose, can be used applied to other situations where we want to allow registration moving forward (types, property-accessor, etc).
--
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
12 years, 9 months
[Hibernate-JIRA] Created: (HHH-2764) EntityType.deepCopy needs to copy for EntityType.DOM4J
by Alan Krueger (JIRA)
EntityType.deepCopy needs to copy for EntityType.DOM4J
------------------------------------------------------
Key: HHH-2764
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2764
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.2
Environment: Hibernate 3.2.2
Reporter: Alan Krueger
Using DOM4J with a set of composite-elements that contains a many-to-one. When loading this from the database, the many-to-one piece of the composite-element is disappearing from the XML. I can see the collection being built and the properties on the elements of the collection being set, but the many-to-one property disappears after that.
Investigating this, it looks like when PersistentElementHolder.getSnapshot is called and a deepCopy is performed, the EntityType.deepCopy method returns the value to be copied rather than copying it. This interacts poorly with the DOM4J tree, since each Element can only have a single Element parent. When the properties are set on this, a detach is performed that yanks the original element out of its parent.
--
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
12 years, 9 months
[Hibernate-JIRA] Created: (HHH-4739) InheritanceType.SINGLE_TABLE don't work with Postgresql 8.4.1 and postgresql-8.4-701.jdbc3.jar
by Robert Anderson Nogueira de Oliveira (JIRA)
InheritanceType.SINGLE_TABLE don't work with Postgresql 8.4.1 and postgresql-8.4-701.jdbc3.jar
----------------------------------------------------------------------------------------------
Key: HHH-4739
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4739
Project: Hibernate Core
Issue Type: Bug
Components: annotations, core, entity-manager, testsuite
Affects Versions: 3.3.1
Environment: JBoss Seam 2.2.0-GA, PostgreSQL 8.4.1, postgresql-8.4-701.jdbc3.jar
Reporter: Robert Anderson Nogueira de Oliveira
Attachments: main-classes.zip
@Entity
public class FenomenoMetadado implements Serializable {
/**
*
*/
private static final long serialVersionUID = 1L;
@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
private Integer id;
@NotNull
private String nome;
private String descricao;
@OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL, mappedBy = "fenomenoMetadado")
private List<AtributoMetadado> atributosMetadado;
/* Getters and Setters */
}
@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
public abstract class AtributoMetadado implements Serializable {
/**
*
*/
private static final long serialVersionUID = 1L;
@Id @GeneratedValue(strategy=GenerationType.IDENTITY)
private Integer id;
@NotNull
private String nome;
@NotNull
private String label;
@NotNull
private Boolean requerido;
@ManyToOne
@JoinColumn(name="fenomenometadado_id", nullable = false)
private FenomenoMetadado fenomenoMetadado;
/* Getters and Setters */
}
@Entity
public class StringMetaDado extends AtributoMetadado {
/**
*
*/
private static final long serialVersionUID = 1L;
}
TestNG:
public class FenomenoMetadadoTests extends SeamTest {
@Test
public void testarCriarRemover() throws Exception {
final FenomenoMetadado instalacaoMetaDado = new FenomenoMetadado();
instalacaoMetaDado.setNome("Instalações");
instalacaoMetaDado.setDescricao("Instalações de Petróleo e Gás");
List<AtributoMetadado> atributos = new ArrayList<AtributoMetadado>();
StringMetaDado att1 = new StringMetaDado();
att1.setLabel("Nome");
att1.setNome("nome");
att1.setRequerido(true);
att1.setFenomenoMetadado(instalacaoMetaDado);
atributos.add(att1);
instalacaoMetaDado.setAtributosMetadado(atributos);
new FacesRequest() {
protected void invokeApplication()
{
EntityManager em = (EntityManager) getValue("#{entityManager}");
try {
em.persist(instalacaoMetaDado);
} catch (Exception e) {
e.printStackTrace();
fail("Hibernate Bug with postgresql-8.4-701.jdbc3.jar");
}
}
}.run();
}
Stacktrace:
Hibernate:
insert
into
FenomenoMetadado
(descricao, nome)
values
(?, ?)
Hibernate:
insert
into
AtributoMetadado
(fenomenometadado_id, label, nome, requerido, DTYPE)
values
(?, ?, ?, ?, 'StringMetaDado')
ERROR [org.hibernate.util.JDBCExceptionReporter] Valor inválido para tipo int : StringMetaDado
javax.persistence.PersistenceException: org.hibernate.exception.DataException: could not insert: [org.domain.geoinfra.entity.StringMetaDado]
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:226)
at org.jboss.seam.persistence.EntityManagerProxy.persist(EntityManagerProxy.java:137)
at org.hibernate.search.jpa.impl.FullTextEntityManagerImpl.persist(FullTextEntityManagerImpl.java:93)
at org.jboss.seam.persistence.EntityManagerProxy.persist(EntityManagerProxy.java:137)
at tests.FenomenoMetadadoTests$2.invokeApplication(FenomenoMetadadoTests.java:74)
at org.jboss.seam.mock.AbstractSeamTest$Request.invokeApplicationPhase(AbstractSeamTest.java:646)
at org.jboss.seam.mock.AbstractSeamTest$Request.emulateJsfLifecycle(AbstractSeamTest.java:595)
at org.jboss.seam.mock.AbstractSeamTest$Request.access$100(AbstractSeamTest.java:177)
at org.jboss.seam.mock.AbstractSeamTest$Request$2.doFilter(AbstractSeamTest.java:497)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.jboss.seam.mock.AbstractSeamTest$Request.run(AbstractSeamTest.java:491)
at tests.FenomenoMetadadoTests.testarCriarRemover(FenomenoMetadadoTests.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:546)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:700)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1002)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:137)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:121)
at org.testng.TestRunner.runWorkers(TestRunner.java:908)
at org.testng.TestRunner.privateRun(TestRunner.java:617)
at org.testng.TestRunner.run(TestRunner.java:498)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:329)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:324)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:296)
at org.testng.SuiteRunner.run(SuiteRunner.java:201)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915)
at org.testng.TestNG.runSuitesLocally(TestNG.java:879)
at org.testng.TestNG.run(TestNG.java:787)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:75)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:127)
Caused by: org.hibernate.exception.DataException: could not insert: [org.domain.geoinfra.entity.StringMetaDado]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:100)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:64)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2186)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2666)
at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:71)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:321)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:130)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:479)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:357)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:130)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:645)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:619)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:623)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:220)
... 50 more
Caused by: org.postgresql.util.PSQLException: Valor inválido para tipo int : StringMetaDado
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.toInt(AbstractJdbc2ResultSet.java:2759)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getInt(AbstractJdbc2ResultSet.java:2003)
at org.jboss.resource.adapter.jdbc.WrappedResultSet.getInt(WrappedResultSet.java:673)
at org.hibernate.id.IdentifierGeneratorFactory.get(IdentifierGeneratorFactory.java:107)
at org.hibernate.id.IdentifierGeneratorFactory.getGeneratedIdentity(IdentifierGeneratorFactory.java:92)
at org.hibernate.id.IdentityGenerator$GetGeneratedKeysDelegate.executeAndExtract(IdentityGenerator.java:98)
at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:57)
... 83 more
If I use the jdbc driver postgresql-8.3-605.jdbc3.jar it works fine.
--
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
12 years, 9 months
[Hibernate-JIRA] Created: (HHH-5235) MultipleHiLoPerTableGenerator infers catalogs and schemas where none should be inferred
by Laird Nelson (JIRA)
MultipleHiLoPerTableGenerator infers catalogs and schemas where none should be inferred
---------------------------------------------------------------------------------------
Key: HHH-5235
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5235
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.2
Environment: Hibernate 3.5.2-Final, H2 database version 1.2.134
Reporter: Laird Nelson
I have a @TableGenerator annotation and an associated @GeneratedValue like this:
@Entity(name = "PostalAddress")
@TableGenerator(
name = "PostalAddressEntityIDGenerator",
table = "JPAGenerators",
pkColumnName = "generatorName",
pkColumnValue = "PostalAddressEntityIDGenerator",
valueColumnName = "generatorValue",
allocationSize = 1
)
public class PostalAddressEntity {
@GeneratedValue(strategy = GenerationType.TABLE, generator = "PostalAddressEntityIDGenerator")
@Id
private long id;
/* etc. */
}
At runtime, the following SQL shows up:
select generatorValue from JPAGenerators.JPAGenerators.JPAGenerators where generatorName = 'PostalAddressEntityIDGenerator' for update
Note the table name repeated three times as though it is both the catalog, the schema and the table name.
It seems that the MultipleHiLoPerTableGenerator, when asked to build its SQL strings for various operations, is told that the schema, the catalog and the table name are all the same.
I was expecting that the catalog would default to "", per the TableGenerator documentation, and that the schema would default to whatever was present in orm.xml's persistence-unit-defaults element.
I can work around this by explicitly spelling out the schema name in my @TableGenerator annotation, but I don't want to put it there (can't, actually). I can also work around this in a JPA-compliant manner by defining my table generator in my orm.xml file, but I don't want to do that either.
--
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
12 years, 9 months