Logging dependency cleanup
by Steve Ebersole
I thought I remember someone (Brett? Strong?) going through an cleaning
up references to logging libraries we no longer use. But I still see
entries in libraries.gradle in master for:
slf4j_api: "org.slf4j:slf4j-api:${slf4jVersion}",
slf4j_log4j12: "org.slf4j:slf4j-log4j12:${slf4jVersion}",
jcl_slf4j: "org.slf4j:jcl-over-slf4j:${slf4jVersion}",
jcl_api:
'commons-logging:commons-logging-api:99.0-does-not-exist',
jcl: 'commons-logging:commons-logging:99.0-does-not-exist',
Did I just dream this?
10 years, 6 months
4.3.0.Beta6 release date
by Steve Ebersole
I tentatively scheduled 4.3.0.Beta6 (which is looking likely to be the
first CR) for November 6th which is the 4 week timebox. Trouble is,
that this is the day I am scheduled to fly back from Rome.
So all in all, this release is likely to happen early or late.
10 years, 6 months
[Search] Dynamic sharding configuration
by Hardy Ferentschik
Hi,
I am currently working on HSEARCH-471 [1] - dynamic sharding. The work is built on Emmanuel's prototype and you find the current code on my fork [2].
Right now I am wondering about how to configure (dynamic) sharding. Here is how things worked prior to dynamic sharding. Basically there two properties
driving the shard configuration:
- hibernate.search.[indexName].sharding_strategy
- hibernate.search.[indexName].sharding_strategy.nbr_of_shards
The first property determines the implementation class of IndexShardingStrategy and the second the number of shards to create. So far we had two implementations
of IndexShardingStrategy, namely NotShardedStrategy and IdHashShardingStrategy.
To configure sharding it was enough to set nbr_of_shards to a value > 1. This would automatically select IdHashShardingStrategy and shard depending on the configured
number of shards. The idea was to make it simple to for the user and only require a single configuration change to enable sharding.
However, it creates inconsistencies. For example what if I select NotShardedStrategy and nbr_of_shards >1?
Or I set a custom sharding strategy which does not care about the number of shards?
IMO the important factor is to set the right sharding strategy and nbr_of_shards should just be a (optional) parameter to the sharding strategy.
With dynamic sharding things get more complicated. Right now you configure dynamic sharding by setting 'nbr_of_shards' to the literal 'dynamic'. This selects under the hood the
right IndexShardingStrategy (DynamicShardingStrategy). I find it misleading on multiple levels. First 'dynamic' is not a number and secondly I want to configure a strategy
not the number of shards. It is also inconsistent with how we select/configure other pluggable components in Search. For that reason I suggest:
- The type of sharding is configured via setting hibernate.search.[indexName].sharding_strategy. 'nbr_of_shards' is a parameter which gets passed to the strategy and which
might get ignored depending on the sharding implementation. Implementations are free to check the property and e.g. print out a warning if the settings does not apply to them
- We introduce short names for the provided sharding strategies - 'none', 'id-hash', 'dynamic'. This will avoid the need to reference concrete implementation classes
- For dynamic sharding we have the additional sub-property 'shard_identity_provider' which specifies the ShardIdentifierProvider (new contract needed for dynamic sharding).
This property is only relevant for dynamic sharding and will be handled in the same way as 'nbr_of_shards'
Thoughts?
--Hardy
[1] https://hibernate.atlassian.net/browse/HSEARCH-472
[2] https://github.com/hferentschik/hibernate-search/compare/HSEARCH-472
10 years, 6 months
Decoupling indexed types from their class definitions
by Sanne Grinovero
Some other projects use Hibernate Search - specifically the engine
module - to bridge their domain model to a Lucene index and take
advantage of its high performance low-level integration with Lucene.
This is generally achieved by indexing a "valueholder" object which
has most logic to create a custom o.a.l.Document in a top level
@ClassBridge, or by using some custom FieldBridges, but has some
strong limitations and feels more like a hack.
In Hibernate Search 5.0 we will make this more flexible, so to move
away from an annotated-entities index engine only to make it easier to
index objects whose "schema" is more flexible than the contraints
imposed by the staticness of a compiled Java class.
We've discussed however to introduce some of these features right now
(in version 4.4), so that we can start exploring the direction
gradually and get some early feedback. In particular what seems to be
troublesome is to implement multiple "user types" using the same type
(java type) as valueholders: the trouble is to filter on the correct
user type where the Hibernate Search APIs expect - as basic filtering
strategy - a java Class instance, or simply to have the flexibility to
configure separate backends for each user type.
So this first refactoring [HSEARCH-1402] will be about moving the
*internal* contract - without changing public APIs - to use a
different identification than the current Class when we lookup for
indexing information for a specific indexed type.
Comments very welcome.
Sanne
- https://hibernate.atlassian.net/browse/HSEARCH-1379 Explicit support
for indexing free-form (dynamic) entities
- https://hibernate.atlassian.net/browse/HSEARCH-1402 Allow explicit
user control of ProjectionConstants.OBJECT_CLASS value during indexing
- https://hibernate.atlassian.net/browse/HSEARCH-1404 More flexibility
than just Class to identify indexing metadata
10 years, 6 months
[HV] Extending ParameterNameProvider contract for other element types
by Gunnar Morling
Hi,
On SO [1], a user asked whether it's possible to report custom names for
property constraint violations, e.g. "nm" as retrieved from the annotation
in this case:
@JsonProperty("nm")
@NotNull
final public String name;
At the moment that's not possible with HV, but one might think about a
contract similar to ParameterNameProvider which returns the reported names
for properties (or even custom names to be used instead of the constants
"<return-value>" and "<cross-parameter>").
It's the first time I came across this requirement but adding support for
this should not be too complex and it might be helpful to some. Any
thoughts?
--Gunnar
[1]
http://stackoverflow.com/questions/18878868/hibernate-validator-and-jacks...
10 years, 6 months
portions of JIRA down
by Brett Meyer
FYI, portions of Hibernate JIRA are currently down. Any ticket that was in an "Awaiting Test Case" state will not work. We're working with Atlassian support to resolve it and will hopefully be back up shortly.
Brett Meyer
Software Engineer
Red Hat, Hibernate ORM
10 years, 6 months
checkNullability when deleting an entity
by Steve Ebersole
Anyone have compelling reasons to continue to call
org.hibernate.engine.internal.Nullability#checkNullability when deleting
an entity?
To a lesser degree, how about reasons for calling
org.hibernate.engine.internal.ForeignKeys.Nullifier#nullifyTransientReferences
when deleting?
10 years, 6 months
[Search] Dynamic Sharding the second
by Hardy Ferentschik
Hi,
here comes a follow up on my previous email regarding configuration of dynamic sharding.
Now I would like to get some feedback on ShardIdentifierProvider. This interface was added for dynamic sharding on
top of DynamicShardingStrategy. Gunnar and I had a discussion around it today [1] and we came to the conclusion that
this interface is actually not needed and just adds confusion in the API.
Really ShardIdentifierProvider is a IndexShardingStrategy in disguise. Add 'forAddtion' and 'forDeletion' to the two 'getShardIdentifier' methods
and you have (almost) an IndexShardingStrategy. The problem seems to be, that in order to implement dynamic sharding the
IndexManagerHolder and EntityIndexBinding are needed. IndexShardingStrategy#initialize does not provide access to these objects which maybe
led to the current design.
In DynamicShardingStrategy this is taken care of by passing IndexManagerHolder and EntityIndexBinding as part of the constructor arguments.
Otherwise DynamicShardingStrategy is just a very thin wrapper delegating to the ShardIdentifierProvider.
If the current IndexShardingStrategy#initialize method would get passed the required information for dynamic sharding, there would be no need
for an additional interface like ShardIdentifierProvider. Dynamic sharding could be implemented with the existing extension points and implementations
would fit better into the current pattern of providing custom implementations.
What we could do is to make DynamicShardingStrategy an interface extending IndexShardingStrategy and adding a second initialise contract
of sorts. This would keep backwards compatibility, but also allow for dynamic sharding by users implementing DynamicShardingStrategy.
At the downside the user would have to write a bit more code, but I think that's acceptable given the more consistent approach towards sharding.
Thoughts?
--Hardy
P.S. In case you guys think that we really should hold on to ShardIdentifierProvider, I would at least suggest to either rename
the two 'getShardIdentifier' methods adding 'forAddition' and 'forDeletion' or even collapse the two into a single method (not sure
whether this is easily possible)
[1] http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/20...
10 years, 6 months
