[Hibernate-JIRA] Updated: (ANN-37) @SqlInsert(), @SqlUpdate(), @SqlDelete(), @Loader()
by Assaf Berg (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-37?page=all ]
Assaf Berg updated ANN-37:
--------------------------
Attachment: custom_entity_loader.patch
I just wrote a patch for the Loader part myself. Looks like you beat me to the punch.
Anyway I would suggest calling the parameter queryRef rather than namedQuery to keep in sync with the hbm naming.
One question though: what about collection loader support?
> @SqlInsert(), @SqlUpdate(), @SqlDelete(), @Loader()
> ---------------------------------------------------
>
> Key: ANN-37
> URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-37
> Project: Hibernate Annotations
> Type: Improvement
> Components: binder
> Versions: 3.1beta3
> Reporter: Emmanuel Bernard
> Priority: Trivial
> Fix For: 3.2.1
> Attachments: custom_entity_loader.patch, customsqlannotations.patch, customsqlannotationsusingcheck.patch
>
>
> @SqlInsert(statement="", callable=false),
> @SqlUpdate(statement="", callable=false),
> @SqlDelete(statement="", callable=false),
> @Loader(namedQuery="")
--
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, 6 months
[Hibernate-JIRA] Commented: (HB-450) Support for Some PostgreSQL Types (Contribution)
by Jeffrey Aguilera (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HB-450?page=com... ]
Jeffrey Aguilera commented on HB-450:
-------------------------------------
OK, I'll take a bite. If this is not the right way to integrate these custom types into Hibernate, what is?
> Support for Some PostgreSQL Types (Contribution)
> ------------------------------------------------
>
> Key: HB-450
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HB-450
> Project: Hibernate2
> Type: Patch
> Components: core
> Reporter: Jesse Costello-Good
> Assignee: Christian Bauer
> Priority: Minor
> Attachments: postgres-ext.tgz
>
>
> Here's some classes to support PostgreSQL circle, lseg, point, inet, string[], box, and polygon types. It includes tests and a build.xml.
> I'm not really sure how to contribute this, so I'll post it here. Feel free to contact me if there is some other way in which I should post this.
--
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, 6 months
[Hibernate-JIRA] Commented: (HHH-1401) session.merge() executes unnecessary updates when one-to-many relationship is defined.
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1401?page=c... ]
Steve Ebersole commented on HHH-1401:
-------------------------------------
So in my testing (against the latest code), the only scenario in which I can reproduce this (I am using the entity's defined in org.hhibernate.test.ops) is when merging an unmodified entity which:
(1) is versioned
(2) has collection which actually has elements
I am still looking into that case.
Can anyone else confirm that they do not see this problem in any other scenarios? The collection I am using is specifically an inverse hierarchical Set...
> session.merge() executes unnecessary updates when one-to-many relationship is defined.
> --------------------------------------------------------------------------------------
>
> Key: HHH-1401
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1401
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.1.1
> Environment: Hibernate 3.1.1
> Postgres 8.03
> Java 1.4.2_09
> Reporter: David Trott
> Assignee: Steve Ebersole
> Fix For: 3.2.1
> Attachments: HHH-1401.zip, HHH1401Test.java, Screenshot-Debug - AbstractPersistentCollection.class - Eclipse SDK .png, TEST-org.hibernate.test.optlock.OptimisticLockTest.txt
>
>
> I am attempting to use the session.merge() functionality in order to synchronize the state of the data coming from the web tier with the database, however I am seeing unnecessary updates (when nothing has changed).
> In order to track down the problem I created a test case with four tables and four classes (A,B,C and D)
> Where:
> A is the parent of B.
> B is the parent of C.
> C is the parent of D.
> And there are no other relationships present.
> All these relationships are bi-directional with the one-to-many side marked as inverse="true" and cascade="all-delete-orphan".
> The merge() is working fine (the data gets updated correctly) except that when there is no change to the data hibernate still runs updates on A,B and C however not on D (D has no one-to-many relationships).
> I am including the code and hibernate mapping for B as it is representative of the code for all the other classes.
> I am no expect on the hibernate implementation, but my suspicion of the cause is when hibernate substitutes a PersistentBag for the ArrayList in the merged object (associated with the session) it detects this as a change and hence triggers the update, unfortunately the data itself has not changed hence no update is necessary.
> FYI: If I change the initialization of the bags from "new ArrayList()" to "new PersistentBag()" the extra updates go away, however then it doesn't save real changes correctly.
> package com.mycompany.dal.transfer.impl;
> import org.apache.commons.lang.builder.EqualsBuilder;
> import org.apache.commons.lang.builder.HashCodeBuilder;
> import org.apache.commons.lang.builder.ToStringBuilder;
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.List;
> import com.mycompany.dal.transfer.interfaces.ADTO;
> import com.mycompany.dal.transfer.interfaces.BDTO;
> import com.mycompany.dal.transfer.interfaces.CDTO;
> import org.apache.commons.collections.Closure;
> import org.apache.commons.collections.CollectionUtils;
> public class BDTOImpl implements BDTO {
> public BDTOImpl () {
> }
> private Long bId;
>
> public Long getBId() {
> return bId;
> }
> public void setBId(Long bId) {
> this.bId = bId;
> }
> private Long concurrentVersion;
>
> public Long getConcurrentVersion() {
> return concurrentVersion;
> }
> public void setConcurrentVersion(Long concurrentVersion) {
> this.concurrentVersion = concurrentVersion;
> }
> // Package level protection so that overrides can access it.
> boolean deleting = false;
> private String name;
> /**
> * Returns the Name.
> *
> * @return String - The Name
> */
> public String getName() {
> return name;
> }
> /**
> * Set the Name.
> *
> * @param name String - The Name.
> */
> public void setName(String name) {
> this.name = name;
> }
> private ADTO a;
> /**
> * Returns the A.
> *
> * @return ADTO - The A.
> */
> public ADTO getA() {
> return a;
> }
>
> public ADTO getAInternal() {
> return a;
> }
> /**
> * Updates the A.
> *
> * @param a - ADTO The A.
> */
> public void setA(ADTO a) {
> if (this.a == a) {
> return;
> }
> if (this.a != null) {
> ((ADTOImpl) this.a).removeBInternal(this);
> }
> this.a = a;
> if (a != null) {
> ((ADTOImpl) a).addBInternal(this);
> }
> }
> public void setAInternal(ADTO a) {
> if (deleting) {
> return;
> }
> if (this.a != a &&
> this.a != null && a != null) {
> throw new IllegalStateException("BDTO cannot be a member of two A collections: " + toString());
> }
> this.a = a;
> }
> private List cs;
> private List csMutable;
> { setCsMutable(new ArrayList()); }
> public List getCsMutable() {
> return csMutable;
> }
> public void setCsMutable(List cs) {
> this.cs = Collections.unmodifiableList(cs);
> this.csMutable = cs;
> }
> public List getCs() {
> return cs;
> }
>
> public void addC(CDTO c) {
> csMutable.add(c);
> ((CDTOImpl) c).setBInternal(this);
> }
> public void addCInternal(CDTO c) {
> csMutable.add(c);
> }
>
> public void removeC(CDTO c) {
> csMutable.remove(c);
> ((CDTOImpl) c).setBInternal(null);
> }
> public void removeCInternal(CDTO c) {
> if (!deleting) {
> csMutable.remove(c);
> }
> }
> public void beforeDelete() {
> // Guard to prevent infinite loop.
> if (deleting) {
> return;
> }
>
> deleting = true;
> if (this.a != null) {
> ((ADTOImpl) this.a).removeBInternal(this);
> }
> CollectionUtils.forAllDo(new ArrayList(csMutable), new Closure() {
> public void execute(Object ob) {
> ((CDTOImpl) ob).beforeDelete();
> }
> });
> }
> public int hashCode() {
> return (new HashCodeBuilder(17,37)
> .append(getBId())
> ).toHashCode();
> }
> public boolean equals(Object o) {
> boolean equals = false;
> if (o != null && o instanceof BDTO) {
> BDTO other = (BDTO) o;
> return (new EqualsBuilder()
> .append(getBId(), other.getBId())
> ).isEquals();
> }
> return equals;
> }
>
> public String toString() {
> return new ToStringBuilder(this)
> .append("bId", getBId())
> .append("name", getName())
> .toString();
> }
> }
> ******************************
> *** Mapping Document ****
> ******************************
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
> "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
> <hibernate-mapping package="com.mycompany.dal.transfer.impl" auto-import="true">
> <class name="com.mycompany.dal.transfer.impl.BDTOImpl" table="b">
> <id name="BId" type="long">
> <column name="b_id" not-null="true"/>
> <generator class="native"/>
> </id>
> <version name="concurrentVersion" column="concurrent_version" type="long"/>
> <property name="Name" type="string">
> <column name="name" length="60" not-null="false"/>
> </property>
> <many-to-one name="AInternal" class="com.mycompany.dal.transfer.impl.ADTOImpl">
> <column name="a_id" not-null="true"/>
> </many-to-one>
> <bag name="CsMutable" cascade="all-delete-orphan" inverse="true">
> <key>
> <column name="b_id" not-null="true"/>
> </key>
> <one-to-many class="com.mycompany.dal.transfer.impl.CDTOImpl"/>
> </bag>
> </class>
> </hibernate-mapping>
> *************************
> *** Generated SQL ****
> *************************
> 05:35:39,887 INFO [STDOUT] Hibernate: select adtoimpl0_.a_id as a1_162_2_, adtoimpl0_.concurrent_version as concurrent2_162_2_, adtoimpl0_.name as name162_2_, bsmutable1_.a_id as a4_4_, bsmutable1_.b_id as b1_4_, bsmutable1_.b_id as b1_164_0_, bsmutable1_.concurrent_version as concurrent2_164_0_, bsmutable1_.name as name164_0_, bsmutable1_.a_id as a4_164_0_, csmutable2_.b_id as b4_5_, csmutable2_.c_id as c1_5_, csmutable2_.c_id as c1_165_1_, csmutable2_.concurrent_version as concurrent2_165_1_, csmutable2_.name as name165_1_, csmutable2_.b_id as b4_165_1_ from a adtoimpl0_ left outer join b bsmutable1_ on adtoimpl0_.a_id=bsmutable1_.a_id left outer join c csmutable2_ on bsmutable1_.b_id=csmutable2_.b_id where adtoimpl0_.a_id=?
> 05:35:39,992 INFO [STDOUT] Hibernate: select ddtoimpl0_.d_id as d1_168_0_, ddtoimpl0_.concurrent_version as concurrent2_168_0_, ddtoimpl0_.name as name168_0_, ddtoimpl0_.c_id as c4_168_0_ from d ddtoimpl0_ where ddtoimpl0_.d_id=?
> 05:35:40,007 INFO [STDOUT] Hibernate: select dsmutable0_.c_id as c4_1_, dsmutable0_.d_id as d1_1_, dsmutable0_.d_id as d1_168_0_, dsmutable0_.concurrent_version as concurrent2_168_0_, dsmutable0_.name as name168_0_, dsmutable0_.c_id as c4_168_0_ from d dsmutable0_ where dsmutable0_.c_id=?
> *** Start Extra Updates **
> 05:35:40,030 INFO [STDOUT] Hibernate: update b set concurrent_version=?, name=?, a_id=? where b_id=? and concurrent_version=?
> 05:35:40,038 INFO [STDOUT] Hibernate: update c set concurrent_version=?, name=?, b_id=? where c_id=? and concurrent_version=?
> 05:35:40,044 INFO [STDOUT] Hibernate: update a set concurrent_version=?, name=? where a_id=? and concurrent_version=?
> *** End Extra Updates **
> **************************
> *** Accessing code ****
> **************************
> DataAccessLayer dal = DataAccessLayerBuilder.getInstance();
>
> ADAO aDAO = dal.getADAO();
> BDAO bDAO = dal.getBDAO();
> CDAO cDAO = dal.getCDAO();
> DDAO dDAO = dal.getDDAO();
>
> ADTO a = aDAO.newA();
> a.setAId(new Long(1));
> a.setConcurrentVersion(new Long(0));
> a.setName("A");
>
> BDTO b = bDAO.newB();
> CDTO c = cDAO.newC();
> DDTO d = dDAO.newD();
> b.setBId(new Long(2));
> c.setCId(new Long(3));
> d.setDId(new Long(4));
> b.setConcurrentVersion(new Long(0));
> c.setConcurrentVersion(new Long(0));
> d.setConcurrentVersion(new Long(0));
> b.setName("B");
> c.setName("C");
> d.setName("D");
> b.setA(a);
> c.setB(b);
> d.setC(c);
>
> aDAO.mergeA(a);
--
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, 6 months
[Hibernate-JIRA] Commented: (HHH-1258) startup time improvements
by Tyler Van Gorder (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=c... ]
Tyler Van Gorder commented on HHH-1258:
---------------------------------------
oh...sorry, that makes sense. Offloading CPU intensive work to a background thread(s) is a cool idea. 8-)
> startup time improvements
> -------------------------
>
> Key: HHH-1258
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1 rc3
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Attachments: SessionFactoryImpl.java, SessionFactoryImpl.patch
>
>
> while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it:
> Initial tests where 100 classes, 30 sec for buildSessionFactory
> setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory.
> (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact)
> Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property.
> (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors)
> Other 20% of the time is done in net.sf.cglib related classes for build time enhancement.
> The rest of the time is Configuration creation (can be cached) and other iteration code.
> (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests
> is done on pojos with a "high" method count (approx 100)
--
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, 6 months
[Hibernate-JIRA] Closed: (HHH-1651) hibernate does not find an existing sequence from an Oracle database
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1651?page=all ]
Max Rydahl Andersen closed HHH-1651:
------------------------------------
Fix Version: 3.2.1
Resolution: Fixed
was fixed by another recent patch. please test.
> hibernate does not find an existing sequence from an Oracle database
> --------------------------------------------------------------------
>
> Key: HHH-1651
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1651
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.2.0 cr1
> Environment: Oracle 9i on Linux, Windows 2000, Hibernate-3.2, Hibernate-Annotations-3.1beta9
> Reporter: Olaf Bigalk
> Priority: Trivial
> Fix For: 3.2.1
>
> Original Estimate: 2 hours
> Remaining: 2 hours
>
> I have setup a hibernate project with a few classes using id generation by the @Id @Generated annotation.
> The schema update fails due to the following error:
> ...
> 07.04.2006 15:12:07 org.hibernate.tool.hbm2ddl.DatabaseMetadata getTableMetadata
> INFO: table not found: schema.hibernate_sequence
> 07.04.2006 15:12:07 org.hibernate.tool.hbm2ddl.DatabaseMetadata getTableMetadata
> INFO: table not found: hibernate_sequence
> 07.04.2006 15:12:08 org.hibernate.tool.hbm2ddl.SchemaUpdate execute
> SCHWERWIEGEND: Unsuccessful: create sequence schema.hibernate_sequence
> 07.04.2006 15:12:08 org.hibernate.tool.hbm2ddl.SchemaUpdate execute
> SCHWERWIEGEND: ORA-00955: name is already used by an existing object
> ...
> The error ocures because hibernate searches for existing sequences by the full qualified sequence name (i.e. "schema.hibernate_sequence") but it has retrieved the existing sequences from the database metadata with its unqualified names (i.e. "hibernate_sequence") . Hence it doess not find the existing sequence.
> Then it tries to create the pretended non existing sequence and fails.
> The relevant code ist found in org.hibernate.tool.hbm2ddl.DatabaseMetadata
> public boolean isSequence(Object key) {
> return key instanceof String && sequences.contains( ( (String) key ).toLowerCase() );
> }
> It should be somthing like this:
> public boolean isSequence(Object key) {
> if (key instanceof String) {
> String keyString = (String) key;
>
> if (sequences.contains( keyString.toLowerCase() ) {
> return true;
> }
> String [] strings = StringHelper.split(".", keyString);
> if(strings.length==3) {
> return sequences.contains( strings[2].toLowerCase();
> } else if (strings.length==2) {
> return sequences.contains( strings[1].toLowerCase();
> }
> }
--
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, 6 months
[Hibernate-JIRA] Commented: (HHH-1258) startup time improvements
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=c... ]
Max Rydahl Andersen commented on HHH-1258:
------------------------------------------
I don't think more cpu's will help since alot of this is io related + classloading/creation will be synchronized anyway.....but worth a try if someone feels for it ;)
(I would rather find improvements that doesn't rely on dual cores ;)
> startup time improvements
> -------------------------
>
> Key: HHH-1258
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1 rc3
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Attachments: SessionFactoryImpl.java, SessionFactoryImpl.patch
>
>
> while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it:
> Initial tests where 100 classes, 30 sec for buildSessionFactory
> setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory.
> (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact)
> Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property.
> (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors)
> Other 20% of the time is done in net.sf.cglib related classes for build time enhancement.
> The rest of the time is Configuration creation (can be cached) and other iteration code.
> (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests
> is done on pojos with a "high" method count (approx 100)
--
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, 6 months
[Hibernate-JIRA] Commented: (HHH-1258) startup time improvements
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=c... ]
Emmanuel Bernard commented on HHH-1258:
---------------------------------------
I know what your patch does. But this JIRA issue seems to be the root/container of the startup improvement ideas :-)
> startup time improvements
> -------------------------
>
> Key: HHH-1258
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1 rc3
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Attachments: SessionFactoryImpl.java, SessionFactoryImpl.patch
>
>
> while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it:
> Initial tests where 100 classes, 30 sec for buildSessionFactory
> setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory.
> (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact)
> Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property.
> (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors)
> Other 20% of the time is done in net.sf.cglib related classes for build time enhancement.
> The rest of the time is Configuration creation (can be cached) and other iteration code.
> (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests
> is done on pojos with a "high" method count (approx 100)
--
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, 6 months
[Hibernate-JIRA] Commented: (HHH-1258) startup time improvements
by Tyler Van Gorder (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=c... ]
Tyler Van Gorder commented on HHH-1258:
---------------------------------------
Hi Emmanuel,
The patch I had submitted was not intended to speed up the startup time via a background thread, but rather it loads all of the configuration at startup, but does NOT instrument the persistent beans until they are used. The net affect is that when doing your unit tests, hibernate ONLY instruments the beans that are used for the unit test. The results are dramatic when you have a large number of persistent classes (we have 360+).
We have been using this "patch" in our testing environment for about a month now and we haven't encountered any problems.
Max, I found a small problem with my patch, in that I was not lazy-instrumenting the beans when requests to the classmeta data are made to the session factory. I fixed this problem, I will try to get a patch to you.
Thanks.
Tyler.
> startup time improvements
> -------------------------
>
> Key: HHH-1258
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1 rc3
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Attachments: SessionFactoryImpl.java, SessionFactoryImpl.patch
>
>
> while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it:
> Initial tests where 100 classes, 30 sec for buildSessionFactory
> setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory.
> (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact)
> Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property.
> (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors)
> Other 20% of the time is done in net.sf.cglib related classes for build time enhancement.
> The rest of the time is Configuration creation (can be cached) and other iteration code.
> (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests
> is done on pojos with a "high" method count (approx 100)
--
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, 6 months