[Hibernate-JIRA] Created: (ANN-469) bulk update with native sql queries
by Amir Pashazadeh (JIRA)
bulk update with native sql queries
-----------------------------------
Key: ANN-469
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-469
Project: Hibernate Annotations
Type: Improvement
Components: binder
Versions: 3.2.0.ga
Reporter: Amir Pashazadeh
Priority: Critical
Hibernate Annotations 3.2 does not support bulk update/deletes using native queries,
if I have something like:
@NamedNativeQuery(name = "testQuery", query = "delete from tb_test where id = ?")
in one of my entities, there will be following exception during build of SessionFactory :
Exception in thread "main" org.hibernate.cfg.NotYetImplementedException: Pure native scalar queries are not yet supported
at org.hibernate.cfg.annotations.QueryBinder.bindNativeQuery(QueryBinder.java:118)
at org.hibernate.cfg.annotations.QueryBinder.bindNativeQueries(QueryBinder.java:197)
at org.hibernate.cfg.AnnotationBinder.bindQueries(AnnotationBinder.java:281)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:404)
at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:452)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:268)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1210)
------
I made a mistake and I reported this issue as HHH-2147 as an issue about Hibernate core! :(
--
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
11 years, 9 months
[Hibernate-JIRA] Created: (OGM-151) Reduce memory consumption by sharing the metadata information of Key objects
by Emmanuel Bernard (JIRA)
Reduce memory consumption by sharing the metadata information of Key objects
----------------------------------------------------------------------------
Key: OGM-151
URL: https://hibernate.onjira.com/browse/OGM-151
Project: Hibernate OGM
Issue Type: Improvement
Components: core
Reporter: Emmanuel Bernard
Today EntityKey, AssociationKey, RowKey are composed of a metadata part (table name and column names) and a data part (column values).
Besides, AssociationKey also embeds collection role and owner's EntityKey.
We could have a model where Key object receive a KeyMetadata object whose instances is shared and kept in Persister/Loader. This will reduce memory consumption.
We can in addition consider putting non identifier metadata in a separate object (collection role and entity key owner information) and pass this object to the GridDialect. This object could even be specialized per datastore based on specific metadata hosted on entity / associations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[Hibernate-JIRA] Created: (OGM-150) memory consumption of AssociationKey
by Sanne Grinovero (JIRA)
memory consumption of AssociationKey
------------------------------------
Key: OGM-150
URL: https://hibernate.onjira.com/browse/OGM-150
Project: Hibernate OGM
Issue Type: Improvement
Reporter: Sanne Grinovero
Each AssociationKey is containing several fields which are related to the specific Role of the collection, and could be wrapped in a single object reusable for the specific role.
We could avoid exposing this object from the AssociationKey interface, so that the specific Dialect can define custom metadata.
Goals:
- reuse the object instances
- make sure that AssociationKey instances, which are potentially as many as the association instances in some configurations (not using custom serialization), have the minimum number of fields defined.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[Hibernate-JIRA] Created: (HHH-5855) The method "merge" from the EntityManager causes a duplicated "insert" of a child entity.
by Seth Martin (JIRA)
The method "merge" from the EntityManager causes a duplicated "insert" of a child entity.
-----------------------------------------------------------------------------------------
Key: HHH-5855
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5855
Project: Hibernate Core
Issue Type: Bug
Components: annotations, core, entity-manager
Affects Versions: 3.6.0, 3.3.1
Environment: Hibernate-Core 3.6.0, Hibernate EntityManager 3.6.0, Derby, Spring 3.0.5 (Configuration), JUnit 4.5
Reporter: Seth Martin
Priority: Critical
Attachments: CascadeMergeTest.zip
The method "merge" from the EntityManager causes a duplicated "insert" of a child entity.
Related to HHH-3332
h3.Observed Behavior:
When you have an Entity A with a OneToMany(fetch=LAZY, cascade=ALL or (MERGE and PERSIST)) relationship to another Entity B and attempt to add an new B instance to A hibernate will generate a duplicate insert command upon commit.
I have witnessed this problem occurring when this procedure is followed:
# retrieve an instance of A from persistence (A a = em.find(A.class, id))
# add a new B to A (a.getBs.add(new B()))
# merge instance 'a' back into persistence (em.merge(a))
Upon transaction commit hibernate will generate an additional "insert" statement and insert the new instance of b into the data source twice.
h3.Expected behavior:
I would expect hibernate to only perform a single insertion when 'a' is merged back to persistence and the B's are created through the cascade.
h3.Notes (Discoveries):
This problem can be worked around by:
* Changing the OneToMany relationship from a List to a Set
* Only using either Cascade MERGE or PERSIST not both of ALL
* Add a new B to A.getBs by adding to the '0' index (a.getBs.add(0,new B()))
--
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
11 years, 10 months