[Hibernate-JIRA] Created: (HHH-5470) FirebirdDialect: invalid limit strings when SQL comments are enabled
by Aleš Smodiš (JIRA)
FirebirdDialect: invalid limit strings when SQL comments are enabled
--------------------------------------------------------------------
Key: HHH-5470
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5470
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Hibernate 3.3.1, Firebird 2.1.3
Reporter: Aleš Smodiš
Attachments: FirebirdDialectTest.java, hibernate-core-3.3.1-FirebirdDialect.patch
When using Hibernate with the Firebird database and configuring {{hibernate.use_sql_comments=true}}, the FirebirdDialect inserts the keywords "first" and "skip" at a fixed position in the given SQL clause with the offset 6, which is okay when a plain SQL clause is given so the "select" keyword is always there at the beginning, but produces invalid SQL clauses when commenting inside SQL is enabled.
For example, when I enable comments in my project, the generated SQL is:
{code:sql}
/* cri first ?teria query */ select
this_.id as id0_0_,
this_.name as name0_0_
from
product this_
{code}
I've made a patch that corrects the issue, so e.g. the above example is generated correctly:
{code:sql}
/* criteria query */ select
first ? this_.id as id0_0_,
this_.name as name0_0_
from
product this_
{code}
The patch and a test case for the issue are attached.
--
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
14 years, 2 months
[Hibernate-JIRA] Created: (HBX-1000) Problem with PostgreSQL using uppercase letters in tables
by Ruediger Engelberger (JIRA)
Problem with PostgreSQL using uppercase letters in tables
---------------------------------------------------------
Key: HBX-1000
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1000
Project: Hibernate Tools
Issue Type: Bug
Components: reverse-engineer
Affects Versions: 3.2.beta11
Environment: Hibernate 3.2.5.ga, Hibernate Tools 3.2.0 beta9a, PostgreSql 8.2, postgresql-8.2-506.jdbc3.jar, Eclipse 3.3.0, all running on Windows XP at the moment (including PostgreSql)
Reporter: Ruediger Engelberger
I have problems using Hibernate tools when using upper case letters in a PostgreSQL database.
I can configure Hibernate Tools for my local PostgreSql installation without any problems. I can access the table structure in the view Hibernate Configurations and do reverse engineering by creating XML mappings and beans. No problem.
But when I'm using upper case characters in table names Hibernate Tools can't access the table structures any more. Hibernate Configuration shows the tables, but when I want to see the columns, it doesn't show anything. Reverse engineering also doesn't work any more.
So, the following works:
TABLE cms_clusterMessage
pk_clustermessageid
fk_clusternodeid
messagetype
messagedetail
The following doesn't work:
TABLE cms_clusterMessage
PK_ClusterMessageId
FK_ClusterNodeId
MessageType
MessageDetail
I tried to use different JDBC drivers because I thought it could be a bug of the driver. But it wasn't.
--
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
14 years, 2 months
[Hibernate-JIRA] Created: (HHH-5460) Variable naming when expanding collection-values JPQL parameters causes name collisions
by Simon Dierl (JIRA)
Variable naming when expanding collection-values JPQL parameters causes name collisions
---------------------------------------------------------------------------------------
Key: HHH-5460
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5460
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Hibernate 3.3.1 as provided by JBoss 5.1.0.GA on Ubuntu x86_64 8.10 and Oracle (Sun) Java 1.6.0_20 using PostgreSQL 8.4.4
Reporter: Simon Dierl
Priority: Minor
When issuing a JPQL query to the database that uses multiple, similarly named, collection-valued parameters that have names ending in numbers, such as :foo0, :foo1, ..., :foo11, the parameters are internally expanded to foo00_, foo01_, so IN(:foo0) becomes IN($foo00_, foo01_, ...) Unfortunately, this means that the 11th element of :foo1 becomes $foo110_ and the 1st element of :foo11 becomes $foo110_ AS WELL. This causes the generation of erroneous database requests, the loss of rows that should be returned and the return of rows that were not requested. In the SQL query, the SQL variables are assigned incorrect values.
Workaround: Do not use JPQL parameters that end in numbers, terminate with letters (:foo0x, :foo1x, ..., :foo11x).
--
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
14 years, 2 months
[Hibernate-JIRA] Commented: (HHH-1749) Convert discriminator field value into class name or class when discriminator field purposedly returned in query
by Xavier Dury (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1749?page=c... ]
Xavier Dury commented on HHH-1749:
----------------------------------
Hi, I would also like to be able to retrieve the entity-name/class-name through a query.
My use-case is the following:
We have an entity A (id, description, bigLobContent) and some other entities B and C which both extend A.
We want to show the user a list of A's without loading bigLobContent, so we have a special View/DTO:
"select new ADTO(a.id, a.description, a.class) from A a where ..."
but we would like to keep and display the real type of object the DTO was referring to.
Actually, doing something like
"select a.id, a.description, a.class from A a"
will result in something like [42, 'blah', 2] whereas
"select a.class from A a"
will give an error.
> Convert discriminator field value into class name or class when discriminator field purposedly returned in query
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HHH-1749
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1749
> Project: Hibernate Core
> Issue Type: Improvement
> Affects Versions: 3.0.5
> Environment: Win XP SP2, JDK 1.5.0_05, Hibernate 3.0.5
> Reporter: Ignat Zapolsky
>
> It is possible to obtain discriminator field by specifying it in query, it is possible to use it since hibernate automatically replaces entity.class with discriminator column and converts class into associated discriminator value. But retreival of such field is useless since user cannot obtain .class from returned discriminator value and Hibernate expects .class, not discriminator in queries.
> Sample query : select cat.class from my.Cat as cat where ...
--
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
14 years, 2 months
[Hibernate-JIRA] Created: (HHH-5458) Intermittent Failure: Occaisonally Hibernate/JBoss fails to push updates to the Database
by Stephen Davidson (JIRA)
Intermittent Failure: Occaisonally Hibernate/JBoss fails to push updates to the Database
----------------------------------------------------------------------------------------
Key: HHH-5458
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5458
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.4.sp1
Environment: JBoss 4.2.2.GA
MS 2003 (Polish CharacterSet)
Reporter: Stephen Davidson
Priority: Minor
Occurs on one system intermittently. When an exception occurs (non-db related) during a transaction, any changes to any Session managed objects after are not persisted to the database unless EntityManager.saveOrUpdate is explicitly called with the managed object. This continues for any later transaction, and persists through JBoss restarts. The only way to fix this once it starts is to stop JBoss, delete the %JBOSS_HOME%/server/<config>/data & work directories, the restart JBoss.
Unfortunately, we have not been able to reliably duplicate the cause, and it only happens sometimes, once every 2-3 weeks. Its the same server every time, but only on that one server (which is not even anything resembling the most heavily loaded server, but one of the lightest loaded).
I attempted to discuss this first on IRC, but there did not seem to be anyone on the #hibernate channel today.
I am completely at a loss for this, and due to the inconsistent showing of this issue, have not yet been unable to come up with a test case (there have been several days worth of effort to come up with a test case by each of several developers on the team). If anyone knows what is causing this issue, assistance would be appreciated.
--
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
14 years, 2 months