[Hibernate-JIRA] Updated: (HHH-1615) GROUP BY entity does not work
by Christian Bauer (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1615?page=all ]
Christian Bauer updated HHH-1615:
---------------------------------
type: Improvement (was: Bug)
Priority: Minor (was: Major)
Until this expansion is implemented, use:
select count(foo.bar), foo from Foo foo group by foo.id, foo.all, foo.other, foo.properties, foo.of, foo.entity
> GROUP BY entity does not work
> -----------------------------
>
> Key: HHH-1615
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1615
> Project: Hibernate3
> Type: Improvement
> Components: query-hql
> Versions: 3.1.3
> Environment: PostgreSQL 8.1.3, Hibernate 3.1.3
> Reporter: Xavier Bugaud
> Priority: Minor
>
>
> The query : "select cat, count(*) from Cat cat group by cat" does not work.
> ERROR: column "xxxx" must appear in the GROUP BY clause or be used in an aggregate function
> See :
> - http://forum.hibernate.org/viewtopic.php?t=953716
> - http://jira.nhibernate.org/browse/NH-528
--
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
17 years, 8 months
[Hibernate-JIRA] Resolved: (HHH-1865) Group by does not expand columns
by Christian Bauer (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1865?page=all ]
Christian Bauer resolved HHH-1865:
----------------------------------
Resolution: Duplicate
> Group by does not expand columns
> --------------------------------
>
> Key: HHH-1865
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1865
> Project: Hibernate3
> Type: Bug
> Components: query-hql
> Environment: Windows XP
> JDeveloper 10.1.2.1
> Reporter: Nestor Boscán
> Priority: Minor
>
>
> Hi
> I need to use Hibernate 3.1.3 to create a query that returns an object and a aggregate value like this:
> select max (t.test_date), t from TestTo t.
> Because I have an aggregate function I have to define the GROUP BY clause:
> select max (t.test_date), t from TestTo t group by t
> But I get an error:
> ORA-00979: not a GROUP BY expression
> The generated SQL is:
> select max(testto0_.test_date) as col_0_0_,
> testto0_.test_value as col_1_0_,
> testto0_.test_value as test1_0_,
> testto0_.test_date as test2_0_
> from TEST testto0_
> group by testto0_.test_value
> It seems that Hibernate is expanding all columns of the TestTo class in the SELECT statement but not in the GROUP BY statement.
> The TestTo class:
> public class TestTo
> {
> private int value;
> private Date date;
> public TestTo()
> {
> }
> public int getValue()
> {
> return value;
> }
> public void setValue(int value)
> {
> this.value = value;
> }
> public Date getDate()
> {
> return date;
> }
> public void setDate(Date date)
> {
> this.date = date;
> }
> }
> The Mapping File:
> <hibernate-mapping>
> <class name="mypackage.TestTo" table="TEST">
> <id name="value" column="test_value">
> <generator class="sequence">
> <param name="sequence">seq_test</param>
> </generator>
> </id>
> <property name="date" column="test_date"/>
> </class>
> </hibernate-mapping>
--
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
17 years, 8 months
[Hibernate-JIRA] Created: (HB-1568) Error when running hql on IBM MainFrame z/OS
by Dotan Hen (JIRA)
Error when running hql on IBM MainFrame z/OS
--------------------------------------------
Key: HB-1568
URL: http://opensource.atlassian.com/projects/hibernate/browse/HB-1568
Project: Hibernate2
Type: Bug
Versions: 3.0 rc 1
Environment: MainFrame z/OS
DB - DB2
Dialect: org.hibernate.dialect.DB2390Dialect
Reporter: Dotan Hen
I tried to use Hibernate on MainFrame and it was working fine when I used get and set Objects but when I try to exe sql and hql quereis I recieved the error below Sql to run -> select kpi.id , kpi.value, kpi.key from KPI kpi
Exception in thread "main" org.hibernate.QueryException: unexpected char: 0xA2 [
select kpi.id , kpi.value, kpi.key from KPI kpi]
at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorIm
pl.java:165)
at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl
.java:83)
at org.hibernate.impl.SessionFactoryImpl.getQuery(SessionFactoryImpl.java
at org.hibernate.impl.SessionFactoryImpl.getQuery(SessionFactoryImpl.jav
a:414)
at org.hibernate.impl.SessionImpl.getQueries(SessionImpl.java:821)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:779)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:74)
at TestHiber.exeQuery(TestHiber.java:59)
at TestHiber.main(TestHiber.java:30)
Caused by: line 1:1: unexpected char: 0xA2
at org.hibernate.hql.antlr.HqlBaseLexer.nextToken(HqlBaseLexer.java:279)
at antlr.TokenBuffer.fill(TokenBuffer.java:69)
at antlr.TokenBuffer.LA(TokenBuffer.java:80)
at antlr.LLkParser.LA(LLkParser.java:52)
at org.hibernate.hql.antlr.HqlBaseParser.statement(HqlBaseParser.java:13
0)
--
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
17 years, 8 months
[Hibernate-JIRA] Commented: (HBX-709) Start distributing an eclipse Hibernate Tools runtime only JAR
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-709?page=co... ]
Max Rydahl Andersen commented on HBX-709:
-----------------------------------------
...and now it turns out that the type attribute is deprecated. I removed the whole block now.
> Start distributing an eclipse Hibernate Tools runtime only JAR
> --------------------------------------------------------------
>
> Key: HBX-709
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-709
> Project: Hibernate Tools
> Type: Task
> Reporter: Darryl Miles
> Fix For: 3.2beta8
> Attachments: feature.xml
>
>
> http://forum.hibernate.org/viewtopic.php?t=962374
> Start to pickup and use Eclipse/WTP versioning within the features.xml/
> Plan of action as I see it:
> * Copy features/org.eclipse.* and features.org.apache.* files as well as pre-requisite plugins/* when packaging.
> * Move <plugin ...> into <import ...> in features/org.hibernate.eclipse.feature_3.2.0.beta6a/feature.xml (see attached sample of this working for me)
> * Modify build and packaging process to now create two JARs.
> JAR one contains (this is the runtime only JAR):
> features/org.hibernate.eclipse.feature*
> plugins/org.hibernate.eclipse*
> plugins/org.jboss.ide.eclipse.freemarker*
> JAR two contains (this is the equivalent of what is distrubuted now, hibernate tools, with WTP/XSD/GEF/JEM pre-requisites, without Eclipse Platform)
> All the files in JAR one above, plus
> plugins/org.eclipse.gef*
> plugins/org.eclipse.wst.xml_core.feature.*
> plugins/org.eclipse.wst.common_core.feature*
> plugins/org.eclipse.wst.common_ui.feature*
> plugins/org.apache.xerces.feature*
> plugins/org.eclipse.xsd*
> plugins/org.eclipse.jem*
> plugins/org.eclipse.wst.xml_ui.feature*
> plugins/org.eclipse.emf*
> features/org.eclipse.gef*
> features/org.eclipse.wst.xml_core.feature_*
> features/org.eclipse.wst.common_core.feature_*
> features/org.eclipse.wst.common_ui.feature_*
> features/org.apache.xerces.feature_*
> features/org.eclipse.xsd_*
> features/org.eclipse.jem_*
> features/org.eclipse.wst.xml_ui.feature_*
> features/org.eclipse.emf_*
> By removing the <plugin ..> declarations from the hibernate JAR it stops the JAR claiming it is the authorative source for that plugin to the update manager. By including the original features/ files from the original authorative source means that if a user installs pre-requisites (or has pre-requisites already installed) when they use JAR two, and restart Eclipse will automatically pickup and use the lastest installed version of WTP/XSD/EMF/GEF/JEM compatible with hibernate tools.
> This has the effect is automatically upgrading the version of pre-requisites when multiple versions are found. But in the event the users version of pre-requisites is too old or non-existant then the ones in the JAR two will be picked up and used.
> If the re-packaged version of freemarker is also being used inside other JBOSS plugins, then I would suggest a seperate feature/org.jboss.ide.eclipse.freemarker*/feature.xml be provided and all plugins built on top are then to pickup that with an <import ...> declaration. If hibernate tools is the only user of freemarker then leading it inside hibernate tools is 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
17 years, 8 months
[Hibernate-JIRA] Commented: (HBX-709) Start distributing an eclipse Hibernate Tools runtime only JAR
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-709?page=co... ]
Max Rydahl Andersen commented on HBX-709:
-----------------------------------------
the pde editor actually says update sites for feature.xml....i'm 99% sure it did not say that when i actually added those values almost 2 years ago ;)
> Start distributing an eclipse Hibernate Tools runtime only JAR
> --------------------------------------------------------------
>
> Key: HBX-709
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-709
> Project: Hibernate Tools
> Type: Task
> Reporter: Darryl Miles
> Fix For: 3.2beta8
> Attachments: feature.xml
>
>
> http://forum.hibernate.org/viewtopic.php?t=962374
> Start to pickup and use Eclipse/WTP versioning within the features.xml/
> Plan of action as I see it:
> * Copy features/org.eclipse.* and features.org.apache.* files as well as pre-requisite plugins/* when packaging.
> * Move <plugin ...> into <import ...> in features/org.hibernate.eclipse.feature_3.2.0.beta6a/feature.xml (see attached sample of this working for me)
> * Modify build and packaging process to now create two JARs.
> JAR one contains (this is the runtime only JAR):
> features/org.hibernate.eclipse.feature*
> plugins/org.hibernate.eclipse*
> plugins/org.jboss.ide.eclipse.freemarker*
> JAR two contains (this is the equivalent of what is distrubuted now, hibernate tools, with WTP/XSD/GEF/JEM pre-requisites, without Eclipse Platform)
> All the files in JAR one above, plus
> plugins/org.eclipse.gef*
> plugins/org.eclipse.wst.xml_core.feature.*
> plugins/org.eclipse.wst.common_core.feature*
> plugins/org.eclipse.wst.common_ui.feature*
> plugins/org.apache.xerces.feature*
> plugins/org.eclipse.xsd*
> plugins/org.eclipse.jem*
> plugins/org.eclipse.wst.xml_ui.feature*
> plugins/org.eclipse.emf*
> features/org.eclipse.gef*
> features/org.eclipse.wst.xml_core.feature_*
> features/org.eclipse.wst.common_core.feature_*
> features/org.eclipse.wst.common_ui.feature_*
> features/org.apache.xerces.feature_*
> features/org.eclipse.xsd_*
> features/org.eclipse.jem_*
> features/org.eclipse.wst.xml_ui.feature_*
> features/org.eclipse.emf_*
> By removing the <plugin ..> declarations from the hibernate JAR it stops the JAR claiming it is the authorative source for that plugin to the update manager. By including the original features/ files from the original authorative source means that if a user installs pre-requisites (or has pre-requisites already installed) when they use JAR two, and restart Eclipse will automatically pickup and use the lastest installed version of WTP/XSD/EMF/GEF/JEM compatible with hibernate tools.
> This has the effect is automatically upgrading the version of pre-requisites when multiple versions are found. But in the event the users version of pre-requisites is too old or non-existant then the ones in the JAR two will be picked up and used.
> If the re-packaged version of freemarker is also being used inside other JBOSS plugins, then I would suggest a seperate feature/org.jboss.ide.eclipse.freemarker*/feature.xml be provided and all plugins built on top are then to pickup that with an <import ...> declaration. If hibernate tools is the only user of freemarker then leading it inside hibernate tools is 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
17 years, 8 months
[Hibernate-JIRA] Commented: (HBX-709) Start distributing an eclipse Hibernate Tools runtime only JAR
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-709?page=co... ]
Max Rydahl Andersen commented on HBX-709:
-----------------------------------------
great..so <discovery url=...> which is entered through the PDE ui as "sites to visit get more information" is actually not unless you manually go in and add type="web" to them...fantastic and non-intuitive.
I've updated them to inlucde the proper type.
> Start distributing an eclipse Hibernate Tools runtime only JAR
> --------------------------------------------------------------
>
> Key: HBX-709
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-709
> Project: Hibernate Tools
> Type: Task
> Reporter: Darryl Miles
> Fix For: 3.2beta8
> Attachments: feature.xml
>
>
> http://forum.hibernate.org/viewtopic.php?t=962374
> Start to pickup and use Eclipse/WTP versioning within the features.xml/
> Plan of action as I see it:
> * Copy features/org.eclipse.* and features.org.apache.* files as well as pre-requisite plugins/* when packaging.
> * Move <plugin ...> into <import ...> in features/org.hibernate.eclipse.feature_3.2.0.beta6a/feature.xml (see attached sample of this working for me)
> * Modify build and packaging process to now create two JARs.
> JAR one contains (this is the runtime only JAR):
> features/org.hibernate.eclipse.feature*
> plugins/org.hibernate.eclipse*
> plugins/org.jboss.ide.eclipse.freemarker*
> JAR two contains (this is the equivalent of what is distrubuted now, hibernate tools, with WTP/XSD/GEF/JEM pre-requisites, without Eclipse Platform)
> All the files in JAR one above, plus
> plugins/org.eclipse.gef*
> plugins/org.eclipse.wst.xml_core.feature.*
> plugins/org.eclipse.wst.common_core.feature*
> plugins/org.eclipse.wst.common_ui.feature*
> plugins/org.apache.xerces.feature*
> plugins/org.eclipse.xsd*
> plugins/org.eclipse.jem*
> plugins/org.eclipse.wst.xml_ui.feature*
> plugins/org.eclipse.emf*
> features/org.eclipse.gef*
> features/org.eclipse.wst.xml_core.feature_*
> features/org.eclipse.wst.common_core.feature_*
> features/org.eclipse.wst.common_ui.feature_*
> features/org.apache.xerces.feature_*
> features/org.eclipse.xsd_*
> features/org.eclipse.jem_*
> features/org.eclipse.wst.xml_ui.feature_*
> features/org.eclipse.emf_*
> By removing the <plugin ..> declarations from the hibernate JAR it stops the JAR claiming it is the authorative source for that plugin to the update manager. By including the original features/ files from the original authorative source means that if a user installs pre-requisites (or has pre-requisites already installed) when they use JAR two, and restart Eclipse will automatically pickup and use the lastest installed version of WTP/XSD/EMF/GEF/JEM compatible with hibernate tools.
> This has the effect is automatically upgrading the version of pre-requisites when multiple versions are found. But in the event the users version of pre-requisites is too old or non-existant then the ones in the JAR two will be picked up and used.
> If the re-packaged version of freemarker is also being used inside other JBOSS plugins, then I would suggest a seperate feature/org.jboss.ide.eclipse.freemarker*/feature.xml be provided and all plugins built on top are then to pickup that with an <import ...> declaration. If hibernate tools is the only user of freemarker then leading it inside hibernate tools is 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
17 years, 8 months
[Hibernate-JIRA] Commented: (HBX-709) Start distributing an eclipse Hibernate Tools runtime only JAR
by Darryl Miles (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-709?page=co... ]
Darryl Miles commented on HBX-709:
----------------------------------
If you are not going to point them to an update site, simple dont configure a value. But certainly don't configure a value to a location which you know is not an update site. No user is going to manually open this file to read the URL in there to get it and depending upon which version of Eclipse you have, having a bogus update site configured can cause the update process to bomb out early (throw exceptions). I have another plugin I use which is pointed to a site throwing a HTTP 404 and causes Update Manager not to allow me to get to the package selection page.
There is already the <description url="http://tools.hibernate.org"> which is user clickable URL, this can be accessed from the proprties information about the feature/plugin.
Ideally if you have multiple update sites then based on what you are stating you would have:
Nighties: Omit the <url> elements completely
Development Branch: Point to http://download.jboss.org/jbosside/updates/development/
Stable Branch: Point to http://download.jboss.org/jbosside/updates/stable/
As I say I tried a wide variety of configuration and update options to confirm the original features.xml was exactly and after further experimentation some of the import referenced were turned from plugin reference to feature references.
The point that was being made before was that some features like org.eclipse.wst.common_core.feature, you are already referencing (and redistributing) all the imports of their constituent plugins anyway, so yes it would make things simpler.
I think I understand the point you are maintaining. Since you don't redistribute the features/ files yet; then you can't reference them, sorry I was ahead of myself and already of the mindset you are redistributing the features/ files (as per Plan A listed at the top of this bug report).
But the main problem has been delt with by change over to using imports, now Hibernate Tools is happy to accept and activate a newer version of a plugin instead of insisting on binding to a specific version and accepting no other.
> Start distributing an eclipse Hibernate Tools runtime only JAR
> --------------------------------------------------------------
>
> Key: HBX-709
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-709
> Project: Hibernate Tools
> Type: Task
> Reporter: Darryl Miles
> Fix For: 3.2beta8
> Attachments: feature.xml
>
>
> http://forum.hibernate.org/viewtopic.php?t=962374
> Start to pickup and use Eclipse/WTP versioning within the features.xml/
> Plan of action as I see it:
> * Copy features/org.eclipse.* and features.org.apache.* files as well as pre-requisite plugins/* when packaging.
> * Move <plugin ...> into <import ...> in features/org.hibernate.eclipse.feature_3.2.0.beta6a/feature.xml (see attached sample of this working for me)
> * Modify build and packaging process to now create two JARs.
> JAR one contains (this is the runtime only JAR):
> features/org.hibernate.eclipse.feature*
> plugins/org.hibernate.eclipse*
> plugins/org.jboss.ide.eclipse.freemarker*
> JAR two contains (this is the equivalent of what is distrubuted now, hibernate tools, with WTP/XSD/GEF/JEM pre-requisites, without Eclipse Platform)
> All the files in JAR one above, plus
> plugins/org.eclipse.gef*
> plugins/org.eclipse.wst.xml_core.feature.*
> plugins/org.eclipse.wst.common_core.feature*
> plugins/org.eclipse.wst.common_ui.feature*
> plugins/org.apache.xerces.feature*
> plugins/org.eclipse.xsd*
> plugins/org.eclipse.jem*
> plugins/org.eclipse.wst.xml_ui.feature*
> plugins/org.eclipse.emf*
> features/org.eclipse.gef*
> features/org.eclipse.wst.xml_core.feature_*
> features/org.eclipse.wst.common_core.feature_*
> features/org.eclipse.wst.common_ui.feature_*
> features/org.apache.xerces.feature_*
> features/org.eclipse.xsd_*
> features/org.eclipse.jem_*
> features/org.eclipse.wst.xml_ui.feature_*
> features/org.eclipse.emf_*
> By removing the <plugin ..> declarations from the hibernate JAR it stops the JAR claiming it is the authorative source for that plugin to the update manager. By including the original features/ files from the original authorative source means that if a user installs pre-requisites (or has pre-requisites already installed) when they use JAR two, and restart Eclipse will automatically pickup and use the lastest installed version of WTP/XSD/EMF/GEF/JEM compatible with hibernate tools.
> This has the effect is automatically upgrading the version of pre-requisites when multiple versions are found. But in the event the users version of pre-requisites is too old or non-existant then the ones in the JAR two will be picked up and used.
> If the re-packaged version of freemarker is also being used inside other JBOSS plugins, then I would suggest a seperate feature/org.jboss.ide.eclipse.freemarker*/feature.xml be provided and all plugins built on top are then to pickup that with an <import ...> declaration. If hibernate tools is the only user of freemarker then leading it inside hibernate tools is 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
17 years, 8 months