[Hibernate-JIRA] Created: (HHH-5585) SubDialect of PostgreSQLDialect to support (@Lob + byte[]) combination
by Justin Sands (JIRA)
SubDialect of PostgreSQLDialect to support (@Lob + byte[]) combination
----------------------------------------------------------------------
Key: HHH-5585
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5585
Project: Hibernate Core
Issue Type: Patch
Environment: 3.6.0.CR1, postgresql
Reporter: Justin Sands
Attachments: CustomPostgreSQLDialect.zip
>From hibernate 3.5 to 3.6 the annotation combination @Lob + byte[] does not on postgresql work due to idiosyncrasies in the postgresql JDBC driver.
To support this combination, the following dialect variant can be used along with a basic-type override, provided that the application consistently uses the same annotation style (@Lob + byte[]). A similar approach could be used to support using the OID blob type which postgresql provides, although this patch does not address it.
The user must register the basic type override MateralizedVarBinaryBlobType at boot time.
I am unsure exactly where in the distribution this would fit so I have kept it in one package (org.hibernate.dialect.variant).
I have test cases which I could detach from my current project, if the maintainers think this patch is worth including.
--
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
12 years, 3 months
[Hibernate-JIRA] Created: (HHH-6433) PostCommitListeners are called during rollback
by Shawn Clowater (JIRA)
PostCommitListeners are called during rollback
----------------------------------------------
Key: HHH-6433
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6433
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.2
Environment: JDK 1.6u25, Win7, Oracle10
Reporter: Shawn Clowater
EntityActions that are registered as part of transaction completion are still called when the transaction didn't succeed.
As an example, the DeleteEntityAction
{code}
public void doAfterTransactionCompletion(boolean success, SessionImplementor session) throws HibernateException {
if ( getPersister().hasCache() ) {
final CacheKey ck = new CacheKey(
getId(),
getPersister().getIdentifierType(),
getPersister().getRootEntityName(),
getSession().getEntityMode(),
getSession().getFactory()
);
getPersister().getCacheAccessStrategy().unlockItem( ck, lock );
}
postCommitDelete();
}
{code}
The success is false in the event of a rollback so it doesn't update the cache but it still calls the postCommitDelete which triggers the postCommitDelete listeners. I would think this should only occur in the event that the transaction was actually committed.
To add insult to injury the ActionQueue will also add failed actions to the after transaction completion queue and invalidate the query spaces.
{code}
public void execute(Executable executable) {
try {
executable.execute();
}
finally {
registerCleanupActions( executable );
}
}
private void registerCleanupActions(Executable executable) {
beforeTransactionProcesses.register( executable.getBeforeTransactionCompletionProcess() );
if ( session.getFactory().getSettings().isQueryCacheEnabled() ) {
final String[] spaces = (String[]) executable.getPropertySpaces();
afterTransactionProcesses.addSpacesToInvalidate( spaces );
session.getFactory().getUpdateTimestampsCache().preinvalidate( spaces );
}
afterTransactionProcesses.register( executable.getAfterTransactionCompletionProcess() );
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[Hibernate-JIRA] Created: (HHH-6429) GROUP BY clause doesn't work with composite objects
by Fernando Santos (JIRA)
GROUP BY clause doesn't work with composite objects
---------------------------------------------------
Key: HHH-6429
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6429
Project: Hibernate Core
Issue Type: Bug
Components: query-hql
Affects Versions: 3.6.5
Environment: Firebird 2.1 Server, Hibernate 3.6.5, java 6, eclipse IDE
Reporter: Fernando Santos
Priority: Critical
I'm trying to run the HQL below in the latest hibernate version
{quote}
SELECT
m.account,
(SELECT sum(amount) from Movement where date > '20-02-2011') as primo
FROM
Movement m
GROUP BY
m.account
{quote}
The problem is when the HQL is parsed, the account fields are added to my SELECT query but not to my GROUP BY query like below. Has someone been faced the same problem?
Generated SQL:
{quote}
select movement0_.MOV_ACCOUNT_NUMBER as col_0_0_,
movement0_.MOV_ACCOUNT_AFDELING_ID as col_0_1_,
(select sum(movement2_.MOV_AMOUNT) from MOVEMENT movement2_) as col_1_0_,
account1_.KONTONR as KONTONR12_,
account1_.AFDELING_ID as AFDELING14_12_,
account1_.KON_FUNCTION as KON2_12_,
account1_.KON_BALANCE as KON3_12_,
account1_.KON_BLOCKED as KON4_12_,
account1_.KONTO_NAVN as KONTO5_12_,
account1_.KON_KEY_FIGURE_CODE as KON6_12_,
account1_.KON_MONITORED as KON7_12_,
account1_.KON_SUGGEST_CONTRA_ACC as KON8_12_,
account1_.KON_TOTALFROM as KON9_12_,
account1_.KON_TYPE as KON10_12_,
account1_.UAFD_GRP_NAVN as UAFD11_12_,
account1_.UAFD_NAVN as UAFD12_12_,
account1_.KON_TAX as KON15_12_,
account1_.OPTLOCK as OPTLOCK12_
from MOVEMENT movement0_
inner join KONTOPLAN account1_
on movement0_.MOV_ACCOUNT_NUMBER=account1_.KONTONR
and movement0_.MOV_ACCOUNT_AFDELING_ID=account1_.AFDELING_ID
group by
movement0_.MOV_ACCOUNT_NUMBER,
movement0_.MOV_ACCOUNT_AFDELING_ID
{quote}
Error
{quote}
Caused by: org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544569. Dynamic SQL Error
SQL error code = -104
Invalid expression in the select list (not contained in either an aggregate function or the GROUP BY clause)
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[Hibernate-JIRA] Created: (BVAL-214) Ability to validate an object and a list of changes
by Emmanuel Bernard (JIRA)
Ability to validate an object and a list of changes
---------------------------------------------------
Key: BVAL-214
URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-214
Project: Bean Validation
Issue Type: Improvement
Reporter: Emmanuel Bernard
Pass a list of changes applied to an object graph and validate the object graph had the change been applied.
This is useful for presentation layers like JSF for cross field validations for example.
There are several possibilities to implement that:
1. pass in a Map<String,Object> with the list of changed properties
{code}validator.validateObject(Object model,Map<String,Object> newValues, Class ...profile){code}
2. pass in a set of more typesafe changedset but essentially the same as 1.
{code}changeSet.change("property", value).change("property2", null).remove("collection", index);
validator.validateObject(Object model,ChangeSet changeSet, Class ...profile){code}
3. pass a proxy of the object and apply changes to the proxy. One of the benefits of this approach is that it is transparent to the validator API. The drawback is that the object must be proxyable
{code}User proxiedUser = proxyfier.proxy(user);
proxiedUser.setName("Emmanuel");
proxiedUser.getAddresses().add(address);
validator.validateObject(Object proxiedUser, Class ...profile){code}
More info from Alex
{code} Client side validation already implemented in coming RichFaces 4.0 release, that's not a subject for bean validation. From the JSF side, the cool feature would be object validation that doesn't touch model itself. Currently, we can only validate a single bean attribute aganist new value, that doesn't allow. In richfaces, I do make a 'clone' of target object, update it with new values and perform validation on the cloned object. Would be nice to have something like: validator.validateObject(Object model,Map<String,Object> newValues, Class ...profile) that does a similar work.{code}
--
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
12 years, 3 months