[Hibernate-JIRA] Created: (HSEARCH-219) Manual indexing strategy not implemented
by Fol De Rol (JIRA)
Manual indexing strategy not implemented
----------------------------------------
Key: HSEARCH-219
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-219
Project: Hibernate Search
Issue Type: Bug
Components: engine
Affects Versions: 3.0.1.GA
Reporter: Fol De Rol
Priority: Blocker
It looks impossible to implement fully manual strategy of indexing because of mandating event listeners to be registered.
See org.hibernate.search.util.ContextHelper.java:25:
//FIXME this sucks since we mandante the event listener use
This causes a side effect to my application that stores an indication that the certain object is indexed in a child collection. So, when I complete manual indexing of an object, I add an element to this collection (actually, the cluster node identifier). This causes the Hibernate Search event listener to be triggered because the dependent collection has been modified which in its turn adds one more indexing job. Finally, I get an endless recursion.
--
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
16 years, 3 months
[Hibernate-JIRA] Created: (HSEARCH-238) DirectoryProviderFactory configuration problem
by Rafal Glowacz (JIRA)
DirectoryProviderFactory configuration problem
----------------------------------------------
Key: HSEARCH-238
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-238
Project: Hibernate Search
Issue Type: Bug
Reporter: Rafal Glowacz
Because IdHashShardingStrategy fails after 1.7m ID is reached I decided to use my own version of strategy. I set up property common.hibernate.search.blogentry.sharding_strategy = com. ... .IdShardingStrategy and didn't work for me. As I checked problem exist in DirectoryProviderFactory and the way how properties are created ( new Properties( defaultProperties ) ). This constructor and the way how default properties are stored in this Object this both together doesn't work well. Problem exist:
//define sharding strategy
IndexShardingStrategy shardingStrategy;
Properties shardingProperties = new Properties();
for (Map.Entry entry : indexProps[0].entrySet()) {
if ( ( (String) entry.getKey() ).startsWith( SHARDING_STRATEGY ) ) {
shardingProperties.put( entry.getKey(), entry.getValue() );
}
}
String shardingStrategyName = shardingProperties.getProperty( SHARDING_STRATEGY );
if ( shardingStrategyName == null) {
if ( indexProps.length == 1 ) {
shardingStrategy = new NotShardedStrategy();
}
else {
shardingStrategy = new IdHashShardingStrategy();
}
}
else {
in this loop "for (Map.Entry entry : indexProps[0].entrySet()) {" this set is just empty so custom properties for sharding have been ignored.
Workaround:
Instead using new Properties(defaultProps) I'm using method:
private static Properties createProperties(Properties indexSpecificDefaultProps) {
Properties properties = new Properties();
properties.putAll(indexSpecificDefaultProps);
return properties;
}
--
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
16 years, 3 months
[Hibernate-JIRA] Created: (HSEARCH-239) Search default properties are ignored when at least one shard property exist
by Rafal Glowacz (JIRA)
Search default properties are ignored when at least one shard property exist
----------------------------------------------------------------------------
Key: HSEARCH-239
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-239
Project: Hibernate Search
Issue Type: Bug
Affects Versions: 3.0.0.GA
Reporter: Rafal Glowacz
I'm trying to use shared strategy for search. So my basic setup was:
common.hibernate.search.default.indexBase = /lucene/index
common.hibernate.search.default.optimizer.operation_limit.max = 1000
common.hibernate.search.default.optimizer.transaction_limit.max = 1000
common.hibernate.search.default.directory_provider = org.hibernate.search.store.FSDirectoryProvider
common.hibernate.search.default.sharding_strategy = com.newbay.search.sharding.strategy.IdShardingStrategy
common.hibernate.search.blogentry.sharding_strategy.nbr_of_shards = 5
But this won't work for me because when sharding configuration properties exist then those default ones are completely ignored - I can't understand that. To change this I changed ".default." to ".blogentry." and then I found the bug that the number of properties decides how many shards I want for current index. (nbrOfShards = nbrOfShards >= indexSpecificDefaultProps.size() ?
nbrOfShards :
indexSpecificDefaultProps.size();)
So in this case I can't do anything. I'm looking for such config:
common.hibernate.search.default.indexBase = /lucene/index
common.hibernate.search.default.optimizer.operation_limit.max = 1000
common.hibernate.search.default.optimizer.transaction_limit.max = 1000
common.hibernate.search.default.directory_provider = org.hibernate.search.store.FSDirectoryProvider
common.hibernate.search.default.sharding_strategy = com.newbay.search.sharding.strategy.IdShardingStrategy
common.hibernate.search.website.sharding_strategy.nbr_of_shards = 2
common.hibernate.search.website.indexBase = /lucene/website
common.hibernate.search.blogentry.sharding_strategy.nbr_of_shards = 5
common.hibernate.search.blogentry.indexBase = /lucene/blogentry
But it doesn't work for now.
My solution for this is to build properties in order: default, indexProps, shardProps
//sharded
nbrOfShards = nbrOfShards >= indexSpecificDefaultProps.size() ?
nbrOfShards :
indexSpecificDefaultProps.size();
ensureListSize(indexSpecificProps, nbrOfShards);
for (int index = 0; index < nbrOfShards; index++) {
Properties properties = new Properties();
properties.putAll(defaultProperties);
properties.putAll(indexSpecificDefaultProps);
if (indexSpecificProps.get(index) != null) {
properties.putAll(indexSpecificProps.get(index));
}
indexSpecificProps.set(index, properties);
}
return indexSpecificProps.toArray(new Properties[indexSpecificProps.size()]);
--
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
16 years, 3 months
[Hibernate-JIRA] Created: (HHH-2883) ManyToMany doesn't work with polymorfism
by Dirk (JIRA)
ManyToMany doesn't work with polymorfism
----------------------------------------
Key: HHH-2883
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2883
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.4
Environment: Hibernate 3.2.4, Annotations 3.3.0, Entitymanager 3.3.0
Reporter: Dirk
We tried out the SingleTable inheritance with a ManyToMany
@Entity
@Table(name="SHB_PRINCIPAL")
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name="TYPE",discriminatorType=DiscriminatorType.INTEGER)
@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
public class Principal implements Serializable {
....
@Entity
@DiscriminatorValue(PrincipalType.USER_NR)
@Cache(usage=CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class ApplicationUser extends Principal {
private static final long serialVersionUID = 1L;
@ManyToMany(fetch=FetchType.LAZY, cascade={CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH},
targetEntity=Role.class)
@JoinTable(name="SHB_PRINCIPAL_TO_PRINCIPAL",
joinColumns=@JoinColumn(name="FROM_PRINCIPAL_ID"),
inverseJoinColumns=@JoinColumn(name="TO_PRINCIPAL_ID"))
private Set<Role> roles;
@ManyToMany(fetch=FetchType.LAZY, cascade={CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH},
targetEntity=ApplicationGroup.class)
@JoinTable(name="SHB_PRINCIPAL_TO_PRINCIPAL",
joinColumns=@JoinColumn(name="FROM_PRINCIPAL_ID"),
inverseJoinColumns=@JoinColumn(name="TO_PRINCIPAL_ID"))
private Set<ApplicationGroup> groups;
@Entity
@DiscriminatorValue(PrincipalType.GROUP_NR)
@Cache(usage=CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class ApplicationGroup extends Principal {
private static final long serialVersionUID = 1L;
@ManyToMany(fetch=FetchType.LAZY, cascade={CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH})
@JoinTable(name="SHB_PRINCIPAL_TO_PRINCIPAL",
joinColumns=@JoinColumn(name="TO_PRINCIPAL_ID"),
inverseJoinColumns=@JoinColumn(name="FROM_PRINCIPAL_ID"))
private Set<ApplicationUser> users;
public ApplicationGroup() {
super();
this.type = PrincipalType.GROUP;
}
public Set<ApplicationUser> getUsers() {
return users;
}
public void setUsers(Set<ApplicationUser> users) {
this.users = users;
}
}
But in the groups and the roles of the user, hibernate returns all principals, not only the users or groups. In the query it's clear that the descriminator is NOT used.
--
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
16 years, 3 months
[Hibernate-JIRA] Created: (EJB-360) Create a property to intercept the Configuration for programmatic modification before the EntityManagerFactory is created
by John Leach (JIRA)
Create a property to intercept the Configuration for programmatic modification before the EntityManagerFactory is created
-------------------------------------------------------------------------------------------------------------------------
Key: EJB-360
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-360
Project: Hibernate Entity Manager
Issue Type: New Feature
Components: EntityManager
Affects Versions: 3.3.2.GA
Reporter: John Leach
Attachments: ConfigurationCustomizer.patch
Create a property (hibernate.cfg.customizer) in persistence.xml which allows the user to specify a class which can programmatically modify the constructed Configuration object (built via annotations and XML configuration) before the EntityManagerFactory is created.
The aim is to provide a third mechanism for configuration, after annotation and XML configuration has been performed. By specifying a user supplied class name the user can then use Configuration methods to access the mappings and make programmatic modifications, such as converting Cascade.ALL (JPA) to cascade all-delete-orphans (Hibernate).
The attached patch provides the code modifications, currently used in Spikes, (http://lab.jugtorino.it/trac/sandbox/wiki/Spikes) to allow programmatic modifications of the Configuration object. The patch file was created from the current trunk (18/05/2008) of hibernate-entitymanager, more specifically, trunk/src/java/org/hibernate/ejb.
The user supplied class must have a no argument constructor, and implement the org.hibernate.ejb.ConfigurationCustomizer interface.
The mechanism is similar to hibernate.ejb.interceptor in concept, except that it acts on the Configuration object rather than on the entity life cycle.
--
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
16 years, 3 months
[Hibernate-JIRA] Created: (HHH-2254) A query validation bug produces QueryException: "Expected positional parameter count: 1, actual parameters: [Parent@bec357b] [from Child this where this.id.parent = ?]"
by Hernan Liendo (JIRA)
A query validation bug produces QueryException: "Expected positional parameter count: 1, actual parameters: [Parent@bec357b] [from Child this where this.id.parent = ?]"
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2254
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2254
Project: Hibernate3
Type: Bug
Components: query-hql
Versions: 3.2.0.ga
Environment: Hibernate 3.2 using Sybase. However this is not an environment caused problem. It's supposed to happen in every environment.
Reporter: Hernan Liendo
-- Short description ============================================================================ --
A query validation bug produces QueryException: "Expected positional parameter count: 1, actual parameters: [Parent@bec357b] [from Child this where this.id.parent = ?].
Both Parent and Child use composite keys.
-- Context ====================================================================================== --
Having composite keys for a Parent class and a Child class, I want to retrieve childs that belong to an specific Parent.
-- Parent Definition ============================================================================ --
public class Parent {
public ParentId ParentId;
...
}
public class ParentId {
private String idField1;
private int idField2;
...
}
// the parent mapping
<hibernate-mapping>
<class mutable="false" table="xx" name="Parent">
<composite-id class="ParentId" access="field" name="parentId">
<key-property column="idField1" access="field" name="idField1"/>
<key-property column="idField2" access="field" name="idField2"/>
</composite-id>
</class>
</hibernate-mapping>
-- Child Definition ============================================================================ --
public class Child {
public ChildId childId;
...
}
public class ChildId {
public Parent parent;
public String aditionalIdField;
...
}
// the mapping
<hibernate-mapping>
<class mutable="false" table="yyy" name="Child">
<composite-id class="ChildId" access="field" name="childId">
<key-many-to-one name="parent" class="Parent" access="field">
<column name="idField1" not-null="true" />
<column name="idField2" not-null="true" />
</key-many-to-one>
<key-property column="aditionalIdField" access="field" name="aditionalIdField"/>
</composite-id>
</class>
</hibernate-mapping>
-- HQL Statement ============================================================================ --
from Child this where this.childId.parent = ?
or
from Child this where this.id.parent = ? // using aliased id
-- The Exception ============================================================================ --
org.hibernate.QueryException: Expected positional parameter count: 1, actual parameters: [Parent@bec357b] [from Child this where this.childId.parent = ?]
at org.hibernate.impl.AbstractQueryImpl.verifyParameters(AbstractQueryImpl.java:319)
at org.hibernate.impl.AbstractQueryImpl.verifyParameters(AbstractQueryImpl.java:275)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:75)
...
-- The Problem ============================================================================ --
class: org.hibernate.impl.AbstractQueryImpl
method: protected void verifyParameters(boolean reserveFirstParameter) throws HibernateException
line: 286
The method validates parameters. It resolves the "positionalValueSpan" variable witch in my case gets the value of 2 (One for parent's idField1 and the other for parent's idField2).
The method compares positionalValueSpan (2) with parameterMetadata.getOrdinalParameterCount() witch it is 1 (the quantity of "?" signs in the HQL statement".
This bug only happens when:
1. composed keys are used (and)
2. having a parent-child relationship (and)
3. resolving children from certain parent.
-- Hibernate user workaround ============================================================================ --
Not to use a parent instance variable in the Child class.
Hope this helps. If you guys need the source code in order to check the bug, please let me know it. Good luck!
Hernan
--
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
16 years, 3 months