[Hibernate-JIRA] Created: (HHH-4527) Implements @j.p.Access
by Emmanuel Bernard (JIRA)
Implements @j.p.Access
----------------------
Key: HHH-4527
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4527
Project: Hibernate Core
Issue Type: Sub-task
Components: annotations
Reporter: Emmanuel Bernard
Fix For: 3.5
2.3.1, 2.3.2
"the default access type is determined by the placement of mapping annotations on the
attributes of the entity classes and mapped superclasses of the entity hierarchy that do not explicitly
specify an access type"
"An access type for an individual entity class, mapped superclass, or embeddable class can be specified
for that class independent of the default for the entity hierarchy by means of the Access annotation
applied to the class. This explicit access type specification does not affect the access type of other entity
classes or mapped superclasses in the entity hierarchy."
"When Access(FIELD) is applied to such a class, it is possible to
selectively designate individual attributes within the class for property access. To specify a
persistent property for access by the persistence provider runtime, that property must be desig-
nated Access(PROPERTY) [...] Persistent state inherited from superclasses is accessed in accordance with the access types of
those superclasses."
"When Access(PROPERTY) is applied to such a class, it is possible to selectively designate indi-
vidual attributes within the class for instance variable access. To specify a persistent instance
variable for access by the persistence provider runtime, that instance variable must be desig-
nated Access(FIELD). Persistent state inherited from superclasses is accessed in accordance with the access types of
those superclasses. "
"The access type of an embeddable class is determined by the access type of the entity class, mapped
superclass, or embeddable class in which it is embedded (including as a member of an element collec-
tion) independent of whether the access type of the containing class has been explicitly specified or
defaulted. A different access type for an embeddable class can be specified for that embeddable class
by means of the Access annotation "
So in "summary":
- the default access type of a hierarchy is defined by where annotations are placed (id ideally) on classes that do not override access type
- the @Access type is not inherited to subclasses (the default access type for the hierarchy is inherited) **
- the access type of an embeddable or collection of embeddable, if not set explicitly is the one of its containing class (note the logic is different that in a hierarchy)
- the @Access annotation can be placed on a field to force field access on a class defaulted to property (and vice versa) *
* reverse behavior compared to @o.h.a.AccessType
** I think it's a different behavior than the current @AccessType annotation
If possible, keep support for the legacy @o.h.a.AccessType:
- it supports alternative access strategies
- it will keep legacy apps running :)
--
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
15 years
[Hibernate-JIRA] Created: (HHH-2993) NPE on org.hibernate.hql.ast.HqlSqlWalker, When Using explicit inner join on primitive type
by Vincent YSMAL (JIRA)
NPE on org.hibernate.hql.ast.HqlSqlWalker, When Using explicit inner join on primitive type
--------------------------------------------------------------------------------------------
Key: HHH-2993
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2993
Project: Hibernate3
Issue Type: Bug
Environment: Hibernate 3.2.5ga , oracle 10G, Windows
Reporter: Vincent YSMAL
Hi, trying to make an inne join on a primitve type cause an NPE.
java.lang.NullPointerException
at org.hibernate.hql.ast.HqlSqlWalker.createFromJoinElement(HqlSqlWalker.java:310)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.joinElement(HqlSqlBaseWalker.java:3275)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.fromElement(HqlSqlBaseWalker.java:3067)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.fromElementList(HqlSqlBaseWalker.java:2945)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.fromClause(HqlSqlBaseWalker.java:688)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:544)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectStatement(HqlSqlBaseWalker.java:281)
at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:229)
at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:228)
at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:160)
at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:111)
at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:77)
at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:56)
at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:72)
at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:133)
at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:112)
at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1623)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.orm.hibernate3.HibernateTemplate$CloseSuppressingInvocationHandler.invoke(HibernateTemplate.java:1219)
Trying some HQL like this :
"from Cat as cat inner join cat.name as a0 " cause an NPE
--
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
15 years
[Hibernate-JIRA] Created: (HV-227) hibernate validator message for turkish locale
by Firat KUCUK (JIRA)
hibernate validator message for turkish locale
----------------------------------------------
Key: HV-227
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-227
Project: Hibernate Validator
Issue Type: Patch
Affects Versions: 4.0.0.CR1
Reporter: Firat KUCUK
Attachments: DefaultValidatorMessages_tr.properties
validator.assertFalse=ifadesi hata döndürdü!
validator.assertTrue=ifadesi hata döndürdü!
validator.future=ileriki bir tarih olmalı!
validator.length=uzunluğu {min} ve {max} arasında olmalıdır!
validator.max={value} değerine eşit veya daha küçük olmalıdır!
validator.min={value} değerine eşit veya daha büyük olmalıdır!
validator.notNull=null değer alamaz!
validator.past=geçmiş bir tarih olmalı!
validator.pattern="{regex}" ifadesi ile örtüşmüyor!
validator.range={min} ve {max} arasında olmalıdır!
validator.size=boyut olarak {min} ve {max} arasında olmalıdır!
validator.email=düzgün biçimli bir e-posta adresi değil!
validator.notEmpty=null veya boş değer alamaz!
validator.digits=numerik değil (<{integerDigits} digits>.<{fractionalDigits} digits> bekleniyor!)
validator.creditCard=Geçerli kredi kartı numarası değil!
validator.ean=Geçerli bir EAN değil!
--
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
15 years
[Hibernate-JIRA] Created: (HHH-2399) FlushMode.AUTO practically unusable - should not flush before EVERY query
by Piotr Kołaczkowski (JIRA)
FlushMode.AUTO practically unusable - should not flush before EVERY query
-------------------------------------------------------------------------
Key: HHH-2399
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2399
Project: Hibernate3
Type: Improvement
Versions: 3.1.3, 3.2.1, 3.2.2, 3.2.0.ga
Environment: PostgreSQL 8.1.5, JDBC 2 and 3, Linux kernel 2.4.x, 2.6.x, Java 1.5.0_09
Reporter: Piotr Kołaczkowski
Attachments: hbtest.zip
The method flushIfRequired seems to flush before every query execution, even though there wasn't anything changed to the objects in the session, and the objects in the session are of different class than the object(s) queried. When having more than a few such objects in a session, it may lead to large, unneeded overheads (I noticed 10-200 times slowdown on simple queries). Our system uses many fast queries, that uasually return only one result or few results. The average query durations on different levels, measured by System.nanoTime() (see the attachment):
- database level: 0.05 ms
- pure JDBC code, prepared statements: 0.2 ms
- pure JDBC code, no prepared statements: 0.7 ms
- not cached hibernate query, no other objects associated with the session: 1.3 ms
- cached hibernate query, object in the session cache, no other objects associated with the session: 1.1 ms
- cached hibernate query, 10000 very simple objects of some other class in the session: >50 ms
10000 may seem large, but note these were very simple objects, having only 2 properties. On our production system we have classes with many properties, and even 20 objects in a session can cause a sub-millisecond query to run longer than 5 ms. We switched to FlushMode.COMMIT, and now the performance is much better.
Can you do something about this? As far as I've read in JIRA, a similar issue exists in Hibernate 2.x, and is still OPEN / UNRESOLVED.
BTW. Why is the 1st level cache so slow in my tests? Why reading just a 2 field object from the database cause so much overhead over pure JDBC? What am I doing wrong?
There is so much marketing about using cglib reflection optimizer in the performance FAQ but even if I retrieved these objects using JDBC and reflection, I would achieve much better performance. After all 1 ms is very much time, if getting results from DB and sending them to JVM lasts 0.2 ms.
--
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
15 years
[Hibernate-JIRA] Created: (HHH-4531) Derby dialect should not support comments
by Chris Wilson (JIRA)
Derby dialect should not support comments
-----------------------------------------
Key: HHH-4531
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4531
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2
Environment: Derby 10.5.3.0, Linux
Reporter: Chris Wilson
Our mapping files contain column comments because they are supported on some of our databases. We use hbm2ddl to export the schema to each database. We are now adding support for Derby.
Unfortunately Derby does not support column comments. I get errors like:
ERROR SchemaExport: Unsuccessful: comment on column building_type.description is 'Site Building Type Description'
ERROR SchemaExport: Syntax error: Encountered "comment" at line 1, column 1.
I think that the DerbyDialect should return false for supportsCommentOn(). However it inherits from DB2Dialect which returns true for this property.
Please add the following to DerbyDialect:
public boolean supportsCommentOn() {
return false;
}
--
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
15 years
[Hibernate-JIRA] Created: (HHH-2347) Improvement to DerbyDialect default identy generation mode
by Fabrizio Giustina (JIRA)
Improvement to DerbyDialect default identy generation mode
----------------------------------------------------------
Key: HHH-2347
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2347
Project: Hibernate3
Type: Patch
Versions: 3.2.1
Reporter: Fabrizio Giustina
Attachments: DerbyDialect-identity.diff
although derby supports identities org.hibernate.dialect.DerbyDialect strangely uses an HiLo generation strategy for ids (for any other dialects that support identities IdentityGenerator is the default).
Even more curiously, DerbyDialect overrides getIdentityColumnString() from the Db2 dialect by using "generated ALWAYS as identity" instead of "generated BY DEFAULT as identity". Derby however fully supports "by default" in identities as clarified in http://db.apache.org/derby/docs/10.1/ref/rrefsqlj37836.html .
"by default" should be preferred since it allows a direct insertion when needed (and I can't see no reason why enabling it for db2 and not for derby).
The patch attached simply deletes two methods, so that the default implementation from Db2Dialect is used:
- removing getIdentityColumnString() make derby use "by default" identities like db2 already does
- removing getNativeIdentifierGeneratorClass() make it choose IdentityGenerator.class (it falls back to the default strategy used in org.hibernate.dialect.Dialect)
note that part of this issue has already been reported in HHH-1918 (not addressing the identity generation string)
--
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
15 years