[Hibernate-JIRA] Created: (HHH-2596) Add support for Hypersonic 1.8.0.7
by Gail Badner (JIRA)
Add support for Hypersonic 1.8.0.7
----------------------------------
Key: HHH-2596
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2596
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.2.3
Environment: Hibernate 3.2.3, Hypersonic 1.8.0.7
Reporter: Gail Badner
The version released with Hibernate 3.2.3 (1.8.0.2) is from 2005. It would be good to move to a more recent version.
The following unit tests fail when using Hypersonic 1.8.0.7:
org.hibernate.test.jpa.lock.JPALockTest.testLockModeTypeRead:
Failure: isolation not maintained expected:<lock test> but was:<updated>
org.hibernate.test.legacy.IJ2Test.testUnionSubclass:
Error: could not set a field value by reflection setter of org.hibernate.test.legacy.J.amount
org.hibernate.test.subclassfilter.UnionSubclassFilterTest.testFiltersWithUnionSubclass:
Error: Could not execute JDBC batch update
org.hibernate.test.unionsubclass.UnionSubclassTest.testUnionSubclass:
Failure: junit.framework.AssertionFailedError
org.hibernate.test.unionsubclass.UnionSubclassTest.testUnionSubclassManyToOne
Error: attempt to create delete event with null entity
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-3839) Using Criteria.setMaxResults gives a MySQLSyntaxErrorException
by Kevin DIMEY (JIRA)
Using Criteria.setMaxResults gives a MySQLSyntaxErrorException
--------------------------------------------------------------
Key: HHH-3839
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3839
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Environment: MySQL 5.0.51a
Reporter: Kevin DIMEY
Attachments: hibernate.cfg.xml
Hi,
When trying to limit the number of rows returned by Criteria.list() method, exception is thrown about bad SQL grammar. The "limit" SQL statement is put just after the select keyword. It should be placed at the end of the request.
Moreover, it seems there is no coma between the start row and the amount of objects to retrieve.
Here is the method called :
session.createCriteria(Etude.class).setFirstResult(5).setMaxResults(10).list();
I get the same issue while using only setMaxResults, it puts the "top" keyword just after the "select" one.
Here is the request generated and the stack trace :
Hibernate: select limit ? ? this_.id as id7_6_, this_.avorte_id as avorte11_7_6_, this_.confidentielle as confiden2_7_6_, this_.contact_id as contact12_7_6_, this_.created_at as created3_7_6_, this_.date_fin as date4_7_6_, this_.date_signature as date5_7_6_, this_.date_sollicitation as date6_7_6_, this_.entreprise_id as entreprise13_7_6_, this_.etat_code as etat7_7_6_, this_.numero as numero7_6_, this_.sujet as sujet7_6_, this_.updated_at as updated10_7_6_, avortement2_.id as id1_0_, avortement2_.created_at as created2_1_0_, avortement2_.created_by as created3_1_0_, avortement2_.raison as raison1_0_, contact3_.id as id2_1_, contact3_.adresse_id as adresse18_2_1_, contact3_.civilite_code as civilite2_2_1_, contact3_.connu_par_code as connu3_2_1_, contact3_.connu_par_detail as connu4_2_1_, contact3_.created_at as created5_2_1_, contact3_.entreprise_id as entreprise19_2_1_, contact3_.fax as fax2_1_, contact3_.fonction as fonction2_1_, contact3_.mail as mail2_1_, contact3_.news_dernier_envoi as news9_2_1_, contact3_.news_desinscrit as news10_2_1_, contact3_.nom as nom2_1_, contact3_.parti as parti2_1_, contact3_.prenom as prenom2_1_, contact3_.service_code as service14_2_1_, contact3_.tel_fixe as tel15_2_1_, contact3_.tel_portable as tel16_2_1_, contact3_.updated_at as updated17_2_1_, adresse4_.id as id0_2_, adresse4_.adresse1 as adresse2_0_2_, adresse4_.adresse2 as adresse3_0_2_, adresse4_.adresse3 as adresse4_0_2_, adresse4_.code_postal as code5_0_2_, adresse4_.ville as ville0_2_, entreprise5_.id as id5_3_, entreprise5_.adresse_id as adresse14_5_3_, entreprise5_.created_at as created2_5_3_, entreprise5_.disparue as disparue5_3_, entreprise5_.domaine_code as domaine4_5_3_, entreprise5_.effectif_code as effectif5_5_3_, entreprise5_.etat_code as etat6_5_3_, entreprise5_.fax as fax5_3_, entreprise5_.nom as nom5_3_, entreprise5_.num_siret as num9_5_3_, entreprise5_.particulier as particu10_5_3_, entreprise5_.site_web as site11_5_3_, entreprise5_.tel as tel5_3_, entreprise5_.updated_at as updated13_5_3_, adresse6_.id as id0_4_, adresse6_.adresse1 as adresse2_0_4_, adresse6_.adresse2 as adresse3_0_4_, adresse6_.adresse3 as adresse4_0_4_, adresse6_.code_postal as code5_0_4_, adresse6_.ville as ville0_4_, entreprise7_.id as id5_5_, entreprise7_.adresse_id as adresse14_5_5_, entreprise7_.created_at as created2_5_5_, entreprise7_.disparue as disparue5_5_, entreprise7_.domaine_code as domaine4_5_5_, entreprise7_.effectif_code as effectif5_5_5_, entreprise7_.etat_code as etat6_5_5_, entreprise7_.fax as fax5_5_, entreprise7_.nom as nom5_5_, entreprise7_.num_siret as num9_5_5_, entreprise7_.particulier as particu10_5_5_, entreprise7_.site_web as site11_5_5_, entreprise7_.tel as tel5_5_, entreprise7_.updated_at as updated13_5_5_ from etude this_ left outer join avortement avortement2_ on this_.avorte_id=avortement2_.id left outer join contact contact3_ on this_.contact_id=contact3_.id left outer join adresse adresse4_ on contact3_.adresse_id=adresse4_.id left outer join entreprise entreprise5_ on contact3_.entreprise_id=entreprise5_.id left outer join adresse adresse6_ on entreprise5_.adresse_id=adresse6_.id left outer join entreprise entreprise7_ on this_.entreprise_id=entreprise7_.id
29 mars 2009 00:52:29 org.hibernate.util.JDBCExceptionReporter logExceptions
ATTENTION: SQL Error: 1064, SQLState: 42000
29 mars 2009 00:52:29 org.hibernate.util.JDBCExceptionReporter logExceptions
GRAVE: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'limit 5 10 this_.id as id7_6_, this_.avorte_id as avorte11_7_6_, this_.confident' at line 1
29 mars 2009 00:52:29 org.apache.catalina.core.ApplicationDispatcher invoke
GRAVE: "Servlet.service()" pour la servlet jsp a lanc� une exception
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'limit 5 10 this_.id as id7_6_, this_.avorte_id as avorte11_7_6_, this_.confident' at line 1
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
at com.mysql.jdbc.Util.getInstance(Util.java:381)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1030)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3515)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3447)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1951)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1761)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1912)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208)
at org.hibernate.loader.Loader.getResultSet(Loader.java:1808)
at org.hibernate.loader.Loader.doQuery(Loader.java:697)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
at org.hibernate.loader.Loader.doList(Loader.java:2228)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125)
at org.hibernate.loader.Loader.list(Loader.java:2120)
at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1596)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
at easytic.support.EtudesSupport$EtudesList.getList(EtudesSupport.java:41)
I've attached my hibernate.cfg.xml.
This issue seemed resolved in 3.2.5 : http://opensource.atlassian.com/projects/hibernate/browse/HHH-2954 but I got it with 3.3.1
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-2578) redesign SessionFactory building
by Steve Ebersole (JIRA)
redesign SessionFactory building
--------------------------------
Key: HHH-2578
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2578
Project: Hibernate3
Issue Type: Improvement
Components: core
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Priority: Critical
Fix For: cfg-rework
Currently a SessionFactory is built by throwing a bunch of stuff into a Configuration object, stirring it, letting it come to a boil, and then pulling out the SessionFactory. In seriousness, there are a few problems with the way we currently operate within a Configuration and how we use it to build a SessionFactory:
The general issue that there is no "lifecycle" to when various pieces of information will be available. This is an important omission in a number of ways:
1) consider schema generation. currently we cannot even know the dialect when a lot of db object names are being determined. this would be nice because it would allow us to transparently handle table/column names which are also keywords/reserved-words in the dialect, for example.
2) static-ness of types and the type-mappings. Because we currently have nothing to which to scope them. Ideally a type instance would be aware of the SessionFactory to which it is bound. Instead, what we have now is to change API methods quite a lot of the time to add in the SessionFactory as a passed parameter whenever it is discovered that it is needed.
3) also, most (all?) of the "static" configuration parameters in Hibernate are currently required to be so because of their use from within these static types; thus scoping types would allow us to also scope those config parameters (things like bytecode-provider, use of binary streams, etc).
Ideally what I see happening is a scheme where users build a org.hibernate.cfg.Settings (or something similiar) instance themselves. Additionally they would apply metadata to a registry of some sort (lets call it MetadataRegistry for now). Then in order to build a SessionFactory, they would supply these two pieces of information (via ctor? via builder?). The important aspect though is that the information in MetadataRegistry would not be dealt with until that point in time, which would allow us to guarentee that resolving schema object names, types, etc would have access to the runtime Settings (and specifically the dialect)
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-3807) Adding a restriction to a many-to-one entity in Criteria query causes Join fetching
by Jonathan Gordon (JIRA)
Adding a restriction to a many-to-one entity in Criteria query causes Join fetching
-----------------------------------------------------------------------------------
Key: HHH-3807
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3807
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.3.1
Environment: Hibernate 3.3.1GA
Sql Server 2005
Reporter: Jonathan Gordon
Priority: Minor
When performing a criteria query that includes a restriction on a many-to-one entity, the associated entity is fetched eagerly, as if FetchMode were set to "JOIN". Explicitly setting the FetchMode to "SELECT" does not override this behavior.
For instance, this criteria query:
Criteria criteria = persistenceService.getCriteria(MailingParcel.class)
.createAlias("mailingCampaign", "mc")
.add(Restrictions.ge("mc.id", 1))
.setMaxResults(10);
Yields the following sql:
select
top 10 this_.ID as ID17_1_,
this_.KEYCODE as KEYCODE17_1_,
this_.CAMPAIGN_ID as CAMPAIGN3_17_1_,
this_.MAILING_LIST_MAILING_ID as MAILING4_17_1_,
this_.COUNTRY_LE_ID as COUNTRY5_17_1_,
this_.MATCH_ADDRESS as MATCH6_17_1_,
this_.ADDRESS as ADDRESS17_1_,
this_.MATCH_NAME as MATCH8_17_1_,
this_.FIRST_NAME as FIRST9_17_1_,
this_.LAST_NAME as LAST10_17_1_,
this_.ZIP_CODE asZIP11_17_1_,
this_.CITY as CITY17_1_,
this_.STATE as STATE17_1_,
this_.COMPANY as COMPANY17_1_,
mc1_.ID as ID6_0_,
mc1_.NOTE as NOTE6_0_,
mc1_.NAME as NAME6_0_,
mc1_.DATE_CREATED as DATE5_6_0_,
mc1_.DATE_MODIFIED as DATE6_6_0_,
mc1_.START_DATE as START7_6_0_,
mc1_.SOURCE_FILE_NAME as SOURCE8_6_0_,
mc1_.ORDINAL as ORDINAL6_0_,
mc1_.KEYCODE_SUFFIX as KEYCODE10_6_0_,
mc1_.MATCH_CATALOG_ID as MATCH11_6_0_,
mc1_.ADDRESS_IMPORT_DATE as ADDRESS12_6_0_
from MATCH_MAILING_CAMPAIGN this_
inner join MATCH_CAMPAIGN_INFO mc1_ on this_.CAMPAIGN_ID=mc1_.ID
where mc1_.ID>=1
However, removing the restriction yields the following sql:
select
top 10 this_.ID as ID17_0_,
this_.KEYCODE as KEYCODE17_0_,
this_.CAMPAIGN_ID as CAMPAIGN3_17_0_,
this_.MAILING_LIST_MAILING_ID as MAILING4_17_0_,
this_.COUNTRY_LE_ID as COUNTRY5_17_0_,
this_.MATCH_ADDRESS as MATCH6_17_0_,
this_.ADDRESS as ADDRESS17_0_,
this_.MATCH_NAME as MATCH8_17_0_,
this_.FIRST_NAME as FIRST9_17_0_,
this_.LAST_NAME as LAST10_17_0_,
this_.ZIP_CODE as ZIP11_17_0_,
this_.CITY as CITY17_0_,
this_.STATE as STATE17_0_,
this_.COMPANY as COMPANY17_0_
from MATCH_MAILING_CAMPAIGN this_
Performing the original query in its HQL analog does not have this problem.
--
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
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-2544) Create the EntityPersisters in order based on Inheritance hierarchy
by Shawn Clowater (JIRA)
Create the EntityPersisters in order based on Inheritance hierarchy
-------------------------------------------------------------------
Key: HHH-2544
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2544
Project: Hibernate3
Issue Type: New Feature
Components: core
Affects Versions: 3.2.3
Reporter: Shawn Clowater
Priority: Minor
I have a bit of what might seem to be an odd request.
I had run into a scenario where filters on my mappings that were part of a Single Table hierarchy were not getting into the configuration and it turned out it was based on the order that the EntityPersisters were being created as we've doing some minor magic with Custom EntityPersisters for filters.
In our case we have a filter template where the filter is pretty much the same for each class that implements it except for the table and key name used in the filter.
So, rather than define this annotation everywhere (we had previously been using xdoclet to generate it for the hbm mappings) we pushed the logic into a Custom Persister.
So, essentially as it is building the EntityPersister we intercept the PersistentClass before it calls the super() constructor and add our required filters on the PersistantClass (in its FilterMap) before it gets passed up. This is done like this because by the time it gets to the AbstractEntityPersister's constructor it uses the filterMap to construct the FilterHelper and then you're done as you have no access to change that after it is built.
So, in the Inheritance case any subclasses that are built before the main root class will not have the filters that we inject during the construction of our Custom Entity Persisters. I have temporarily worked around it by changing the Subclasses getFilterMap() method to not only return the filters from the Parent class but also from the class itself. Now, normally you can't define the filter on the subclass but I can through the persister.
What I'd like to do is:
Make the persister class for the subclasses a 'standard' persister that doesn't add any filters to the subclass.
Still have my root class' entity persister adding the filters.
But have the Entity Persisters built in hierarchal order in the SessionFactoryImpl.
Since they are being built in any given order right now, I can't see an issue with providing some order to them, something like the AnnotationBinder does.
--
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
13 years, 2 months