Re: [hibernate-dev] [Search] Redefining inheritance mapping, and why to follow same rules as ORM
by Emmanuel Bernard
On Thu 2014-08-21 19:48, Hardy Ferentschik wrote:
>
> On 21 Jan 2014, at 17:03, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>
> > Your idea of reusing Jandex won't quite fully work when people put their
> > classes in different jars.
>
> Well, the assumption of course is that we can handed a aggregated/composite index
> over all jars.
>
> There is a caveat though, we keep talking that we get the index from a container or
> from ORM, but we need to take care of building our own index as well in case we don’t
> get a Jandex index passed. In this case we need to scan classes.
The hard part (and I did it in Hibernate EM) is
1. to find all jars involved: the discovery mechanism is pretty much
working by accident and classloader hacking
2. to scan the jar: it's easy for zip or directory based JARs, not so
easy for JARS made of different URL prototols and opaque URLs
>
> On the other side, ORM does the Jandex building thing as well on the metamodel branch.
> So I guess that once we depend on ORM 5 we can get in all cases a Jandex index.
> Question is when that will be?
Remember, Hibernate Search is not ORM only. So the discovery mechanism cannot
fully depend on an ORM feature not as a hard dep at least.
11 years, 4 months
[Search] @Transformable vs @ProvidedId
by Sanne Grinovero
There are two annotations clashing for same responsibilities:
- org.infinispan.query.Transformable
- org.hibernate.search.annotations.ProvidedId
as documented at the following link, these two different ways to apply "Id
indexing options" in Infinispan Query, IMHO quite unclear when a user
should use one vs. the other.
-
http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_requirements...
The benefit of @Transformable is that Infinispan provides one out of the
box which will work for any user case: it will serialize the whole object
representing the id, then hex-encode the buffer into a String: horribly
inefficient but works on any serializable type.
@ProvidedId originally marked the indexed entry in such a way that the
indexing engine would consider the id "provided externally", i.e. given at
runtime. It would also assume that its type would be static for a specific
type - which is I think a reasonable expectation but doesn't really hold as
an absolute truth in the case of Infinispan: nothing prevents me to store
an indexed entry of type "Person" for index "personindex" with an Integer
typed key in the cache, and also duplicate the same information under a say
String typed key.
So there's an expectation mismatch: in ORM world the key type is strongly
related to the value type, but when indexing Infinispan entries the reality
is that we're indexing two independent "modules".
I was hoping to drop @ProvidedId today as the original "marker"
functionality is no longer needed: since we have
org.hibernate.search.cfg.spi.SearchConfiguration.isIdProvidedImplicit()
the option can be implicitly applied to all indexed entries, and the
annotation is mostly redundant in Infinispan since we added this.
But actually it turns out it's a bit more complex as it servers a second
function as well: it's the only way for users to be able to specify a
FieldBridge for the ID.. so the functionality of this annotation is not
consumed yet.
So my proposal is to get rid of both @Transformable and @ProvidedId. There
needs to be a single way in Infinispan to define both the indexing options
and transformation; ideally this should be left to the Search Engine and
its provided collection of FieldBridge implementations.
Since the id type and the value type in Infinispan are not necessarily
strongly related (still the id is unique of course), I think this option
doesn't even belong on the @Indexed value but should be specified on the
key type.
Problem is that to define a class-level annotation to be used on the
Infinispan keys doesn't really belong in the collection of annotations of
Hibernate Search; I'm tempted to require that the key used for the type
must be one of those for which an out-of-the-box FieldBridge is provided:
the good thing is that now the set is extensible. In a second phase
Infinispan could opt to create a custom annotation like @Transformable to
register these options in a simplified way.
Even more, I've witnessed cases in which in Infinispan it makes sense to
encode some more information in the key than what's strictly necessary to
identify the key (like having attributes which are not included in the
hashcode and equals definitions). It sounds like the user should be allowed
to annotate the Key types, to allow such additional properties to
contribute to the index definition.
Comments welcome, but I feel strongly that these two annotations need to be
removed to make room for better solutions: we have an opportunity now as
I'm rewriting the mapping engine.
Sanne
11 years, 4 months
Released: Hibernate Search 5.0.0.Alpha6
by Sanne Grinovero
Hi all,
Hibernate Search version 5.0.0.Alpha6 is now available.
I'm skipping the blog post this time as the only significant change
for users is about fixing the Avro based serializer [HSEARCH-1637],
which we had recently broken during 5.0 related refactorings.
We also made it possible to serialize the "Flush" index command
[HSEARCH-1650], and this had us bump the version of the serialization
protocol from 1.0 to 1.1 [HSEARCH-1653].
Regards,
Sanne
11 years, 4 months
JCS Hibernate Region Factory
by Petar Tahchiev
Hi guys,
I would really like to give apache commons jcs a spin (the FAQ says
performancewise it's faster than EHCache) but I don't really know what to
set this property to:
hibernate.cache.region.factory_class
With EHCache and Hibernate 4 I have it set as following:
hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory.class.getCanonicalName()
Any plans to make a region factory for JCS? The guys from jcs team are
pushing for a 2.0 release any minute soon so it might be a good idea to
test now and if you have some suggestions you could ask them to include it
in the 2.0 release.
--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
11 years, 4 months
Unexpected behavior for @PrePersist/@PreUpdate callback when using EntityManager#merge() on transient object
by deepak raut
I have an entity class like -
public class Item {
@Id
//mapping
private Long id;
@ElementCollection
//mapping
private Set<ItemWrapper> wrapperSet;
@Transient
private Map<Item, Boolean> itemPredecessor;
..........
..........
@PrePersist
@PreUpdate
private void populateSet() {
wrapperSet.clear();
for(Map.Entry<Item, Boolean> entry : itemPredecessor.entrySet()) {
wrapperSet.add(...);
}
}
..............
}
What happens is when I call entityManager.merge(...) with newly
instantiated object with itemPredecessor map having some entries in it.
Hibernate invokes callback method populateSet() with copy of instance
passed to merge() which doesn't contain itemPredecessor map with respective
entries as itemPredecessor is marked @Transient. I am using hibernate
4.3.5. Is this the right behavior?
--
Regards,
Deepak A. Raut
11 years, 4 months
Re: [hibernate-dev] what does ""DEBUG [org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl] (EJB default - 6) Skipping JTA sync registration due to auto join checking" mean?
by Robert Heine
Hi,
the missing logfile is now attached to the issue listed below, the
direct link is:
https://issues.jboss.org/secure/attachment/12384220/server-org-jboss-as-j...
Regards,
Rob
On Thu, Aug 14, 2014 at 11:28 AM, Scott Marlow <smarlow at redhat.com>
wrote:
>
> On 08/14/2014 11:59 AM, Steve Ebersole wrote:
>
>> Well it *should* mean that the EM in question was created outside the
>> scope of a transaction. The JPA spec says that in cases of an
>> application-managed PC where the EM is created outside the scope of the
>> JTA txn, the provider should not automatically join the EM to any JTA
>> txn later implicitly. Instead the expectation is for the application to
>> explicitly join the EM to the transaction via the EM.joinTransaction
>> method:
>>
>> <quote>
>> When a JTA application-managed entity manager is used, if the entity
>> manager is created outside the
>> scope of the current JTA transaction, it is the responsibility of the
>> application to join the entity manager
>> to the transaction (if desired) by calling
>> EntityManager.joinTransaction. If the entity man-
>> ager is created outside the scope of a JTA transaction, it is not joined
>> to the transaction unless Entity-
>> Manager.joinTransaction is called.
>> </quote>
>>
>> Note this behavior was made somewhat controllable in JPA 2.1 with the
>> introduction of SynchronizationType.
>>
>> I'd have to refresh my memory on the expectation here wrt
>> container-managed PCs. So that would be my first question to you of the
>> situation... Is this a app or container managed PC?
>>
>> It is odd that they see a "local database transaction" instead though.
>> You sure this isn't a series of auto-commit transactions?
>>
>
> I won't be sure until they enable TRACE logging for org.jboss.as.jpa and
> give us more logs. I'm waiting for that.
>
>
>>
>>
>>
>> On Thu, Aug 14, 2014 at 10:23 AM, Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>> I'm trying to help a user [1] that is complaining that a local
>> database
>> transaction is used, instead of the JTA transaction as they
expect. I
>> asked them to enable TRACE logging for { org.jboss.jca,
org.hibernate,
>> org.jboss.as.jpa + com.arjuna} and see the "Skipping JTA sync
>> registration due to auto join checking" log message.
>>
>> What does the "skipping JTA sync registration due to auto join
>> checking"
>> mean exactly? [2] shows a small example of the log output with an
>> active JTA transaction in use.
>>
>> Scott
>>
>>
>> [1] https://issues.jboss.org/browse/WFLY-3619 XA END / un-enlist for
>> database connection called to early
>>
>> [2] http://fpaste.org/125603/80296401/
>> _______________________________________________
>>
11 years, 4 months
Re: [hibernate-dev] Survey about Licensing of hibernate-orm
by Sanne Grinovero
Hi Christopher,
I'm sorry but I don't understand what you're asking, this project
didn't change licenses. It might contain some classes copied from
Apache2 projects, and some of its components use an ASL2 license (it's
split in independent modules), but no part of Hibernate ORM changed
license.
At best it's possible that your tool found some human error case of
some headers being misplaced and then fixed, but I'm not aware of such
a case.
Regards,
Sanne
On 20 August 2014 04:42, Christopher G Vendome <cvendome(a)cs.wm.edu> wrote:
> Hello,
>
> I'm a Ph.D. student conducting a study on Open Source projects hosted on GitHub with respect to licensing considerations. Specifically, we are interested in understanding the developer rationale for both picking and changing a license. We found your project: "hibernate-orm" experienced the following license change to its files: Apache:2->null:null LGPL:2.1+->null:null (if the change has a null:null value, it represents no license or an unknown license as determined Ninka - a state of the art license extraction tool. Also, patterns are split by a space). If you would be willing to answer a short survey of 6 questions, please respond to the survey below. The answers are strictly for research purposes that we plan to publish. We will keep responses private and if quoted, we will not directly link you to any responses in the publication.
>
> The survey link is: https://wmsurveys.qualtrics.com/SE/?SID=SV_0qQEhAEp08bKEZf
>
> We appreciate your time and thank you for your help understanding developer rationale with respect to software licensing.
>
> Regards,
> Christopher Vendome
> http://www.cs.wm.edu/~cvendome
11 years, 4 months
