[ORM] save vs persist for POST_INSERT generators
by Emmanuel Bernard
Hi Steve,
I've got a quick question.
I sort of remember that we were delaying `persist()` operations - until
flush I suppose. This is something we could not do to `save()` because
`persist()` does not force us to return the id while save does. I am in
particular considering the case where the generator is of type
POST_INSERT like a column identifier.
While browsing the code I could not spot any different between the
handing of a save event and a persist event and the actual SQL executoin
seems to happen duing the `persist()` call as opposed to `flush()`.
Is it that I have dreamt it all? Or did we used to do that but not
anymore?
Emmanuel
11 years, 2 months
Hibernate OGM connecting to JDG's version of Infinispan
by Sanne Grinovero
Hi all,
I didn't try this but I'm wondering if I could use Hibernate OGM with
its Infinispan backend to deploy on JBoss EAP6 and use the Infinispan
build from JDG 6.
Could you make sure this is possible?
I'm expecting some trouble by the fact that depending on Hibernate
*ORM* implicitly or explicitly this will bring along the classpath
visibility of the EAP version of Infinispan (which is not the one we'd
want to use).
For example simply by deploying a JPA based application, we'd get this
version of Infinispan as it's exposed to the application so that it
could be used as a 2nd level cache implementation.
To clarify: the JDG distribution is packaged as a set of JBoss Modules
so you can "layer" them on top of EAP without replacing the Infinispan
& co jars included by the applications server for internal purposes
like session clustering and Hibernate caching.
OGM is for me just one possible case, ultimately we need to make sure
that people using Hibernate can use alternative versions of Infinispan
as well, and not be locked into a specific version by the simple fact
of using JPA: I'm having the same nasty problem with Search: unable to
use JDG for index storage.
Sanne
11 years, 3 months
Re: [hibernate-dev] DuplicateMappingException in ORM 4.3.6.Final
by Scott Marlow
If the cause is allowing the application to deploy with the persistence unit root being the entire EAR, I am interested in feedback on what to do. e.g. throw a deployment exception or log a warning. Logging a warning is probably best, if this is indeed the cause. It might be harsh to fail the deployment, when it might work (if no jar-files are specified).
11 years, 3 months
Re: [hibernate-dev] Projecting an index
by Hardy Ferentschik
Hi Marc,
sorry for the late reply. I forgot to answer :-(
On 5 Jan 2014, at 19:11, Marc Schipperheyn <m.schipperheyn(a)gmail.com> wrote:
> Current situation
> * Loading Wallposts directly from Lucene index.
> * Posts references properties that change relatively often or have cascading indexing impact if they would be saved within the Post document, e.g. User (photo, name, title, link), Classified (photo, title, decription), Group (photo, title, description), Comments (User, user.name, user.link)
> * Posts, Classifieds and Groups can be "Liked", which requires per user post processing because we want to show people liking stuff that are close to you
> * Of groups you can be a member or not so, it also requires post processing on a per user basis
> * In addition, some of these related objects have specific properties such as Event => eventDate, RSVP
>
> So, right now, we're optimizing this post processing process so that the impact is as low as possible. However, because all of these related objects are stored in different indexes it requires multiple hits against the index which has an impact on performance.
>
> Desired situation
> Since a lot of these related objects have common properties: photo, link, title, description and in this case of the Post display purposes we only need a small subset of the properties, it would be desirable to be able to query a single index in a one pass retrieval querying for (object type - id).
Got you.
> The idea of combining all these objects into a single index somehow feels wrong
Why? I would for example assume that in the case of an application using Lucene directly, that there is often just one single index. I agree that it feels natural in Hibernate Search to separate indexes per entity, but
sharing an index in your use case seems reasonable as well. Of course you get a bigger index size which might effect search performance, but on the other hand you now ply target a single index, instead of multiple.
This might even outweigh any performance penalty you get for having a single index.
> and since I don't have any experience doing this, it's hard to oversee the impact of this, including potential bugs because this is not a common use case.
Sure, the only way to know for sure is to actually try and run performance tests. A lot of the required changes would be on a configuration level, so it might not bee too hard to give it a go.
> If I would be able to create a limited "combined secondary index" that would actually meet my use case.
>
> So, this brought me to my original question: can I project properties to a separate index. Which, given my new understanding of combining entities into a single index can also be read as:
> "Can I create two indexes based on a single entity, targeting only a subset of properties, basically duplicating index content”.
The answer to this particular question is no. I don’t think this would also not be so easy to achieve with the current design of the Search codebase. You would somehow need new/additional
configuration options and in the engine itself we probably would have to do a fair bit of shuffling to make it work.
—Hardy
11 years, 3 months
DuplicateMappingException in ORM 4.3.6.Final
by Scott Marlow
I'm working on an application server bug fix that I need some advice
with, as Hibernate ORM 4.3.6.Final is throwing a
"o.h.DuplicateMappingException: Duplicate query mapping
EventManager.MyEvents" after I fixed a jar-file reference bug in WildFly
(when I try to deploy a test case).
Prior to my jar-file bug fix, the jar-file URL was incorrectly pointing
at the wrong location (zero files were returned when file url was
accessed). As a result, entities were loaded only once from the ear/lib
jar. Now, with my bug fix (getJarFileUrls now returns a valid URL for
jar-file) , WildFly is getting the DuplicateMappingException because the
entity is loaded twice (even though *exclude-unlisted-classes* is in the
persistence unit).
I would like to resolve the DME before back porting the "jar-file"
(WildFly) bug fix. I didn't see this behaviour in my ORM 4.2.x testing
(with EAP).
By the way, the getPersistenceUnitRootUrl is the test.ear.
test.ear contents:
lib
test-entities.jar
META-INF
application.xml
MANIFEST.MF
persistence.xml
test-ejb.jar
persistence.xml contents:
<persistence-unit name="jboss-eap-hibernate" transaction-type="JTA">
<jar-file>lib/test-entities.jar</jar-file>
<exclude-unlisted-classes/>
</persistence-unit>
test-entities.jar contents:
META-INF
Event.hbm.xml
EventManager entity class
Event entity class
Event.hbm.xml contents:
<hibernate-mapping package="support.jboss.ejb.entity">
<sql-query name="EventManager.MyEvents">
<load-collection alias="manages" role="EventManager.manages" />
SELECT * FROM EVENT e where e.manager = ?
</sql-query>
Thanks,
Scott
11 years, 3 months
