NoORM team meeting
by Emmanuel Bernard
Main subjects:
- circularity hell between Infinispan Core, Hiebrnate Search, Infinispan
Lucene Directory, Infinispan Query
- OGM plans for beta 3 and beta 4. In particular beta 3 next week
- PRs around Neo4J, cypher dependency problem, remote container support
missing
- OGM and query performance problem
- OGM and embedded structure not requiring a second load and necessary
ORM changes
- Hibernate Search and @IndexedEmbedded(prefix="")
- Prototype on free-form entity
- CI server
Actions:
- Sanne to sum up by email what was agreed on for the Infinispan circularity
problem
- Davide to consider remote access to Neo4J less of a priority than OGM
GA
- Gunnar to open a blocker JIRA on the query performance
- Gunnar to dig up the choice to make ORM more flexible around EntityKey
- Gunnar and Emmanuel to implement above proposed solution in ORM
- Emmanuel to review davide's PR and the one on top of it whatever that
means :)
- Davide to contact Paul Gier on the additional third party dependency
- Emmanuel to read the thread on @IndexedEmbedded
- Sanne to reduce concurrent subjects to make Hibernate Search progress
a priority
- Hardy and Sanne to release Hibernate Search tomorrow
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/...
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/...
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/...
Emmanuel
12 years
@MappedSuperclass, @Embeddable and consistency
by Steve Ebersole
The JPA spec is completely silent on inheritance when it comes to
embeddable classes. When Emmanuel was first developing
hibernate-annotations we decided to allow the use of @MappedSuperclass to
be extended to embeddable classes to control the persistence of attributes
when an embeddable had a superclass.
I want to make sure we are all supporting this consistently. And if not,
whether we need to revisit that original decision.
For example, Gail has recently found inconsistencies in regards to how
envers handles @MappedSuperclass + @Embeddable, compared to ORM.
Specificaly it has different expectations for audited attributes for
@MappedSuperclass when it comes to @Entity versus @Embeddable.
Adam/Lukasz. do you guys see that as a conscious decision? If so, can you
validate why y'all decided to go that way? If it was not a conscious
decision, are there major technical/implementation hurdles to overcome in
making this consistent?
In Search, OGM, etc are we consistent with this interpretation of
@MappedSuperclass + @Embeddable?
12 years
[Search] Handling of mutual dependency with Infinispan
by Sanne Grinovero
Now that finally Infinispan moved to build (and require) Java7, I'm
preparing to upgrade the Lucene Directory to Apache Lucene 4.8.
Sometimes it's trivial, some others we're out of luck and this is one
of such situations: the new Lucene code expects some new methods to
create and validate a CRC32 checksum signature of the Directory
segments.
Not too annoying - I can handle the coding - but it highlights an old
problem which is coming back.
Currently Infinispan is still using Hibernate Search 4.5, and provides
a Lucene Directory for both Lucene versions 3 and 4.
The current build provides the LuceneV4 support as an extension of the
V3 source module; this is a hack we introduced a year ago to make sure
we'd eventually be able to upgrade to Lucene4 and I was hoping now to
finally remove this fishy workaround as I initially expected it to be
a temporary measure.
But in practice such an upgrade of today would have been impossible:
Infinispan also depends on Hibernate Search. Having two different
modules in Infinispan is what enables us today to start an update to a
new version of Lucene.
I'm wondering if we should move the Lucene Directory code into
Hibernate Search; this also has licensing implications as that's using
ASL2 currently. And that's probably only moving the problem one step
down, as Infinispan Query still depends on Hibernate Search (engine)
and the Lucene Directory would still depend on Infinispan Core.
I'm not having a solution in mind; obviously we wouldn't have such a
problem if each of our projects *always* guaranteed a clean migration
path via default methods and deprecated methods, but this is a rule
which is occasionally broken: when it happens, the only thing I can
think of is that one of the two projects needs to release a tag which
has some broken components. For example, Infinispan to release
occasionally without the Query engine.
Sanne
12 years
Re: [hibernate-dev] Build failure executing :hibernate-core:runAnnotationProcessors
by Steve Ebersole
I was having some problems with this as well. First initially setting up
my new machine, I had problems running this using 1.7.0_55 even though I
never previously had problems running previous JDKs. I also saw problems
with this running the build using Java 8 JDK.
All in all I spent some time re-working source generation this week. I
applied my changes to master. I held off porting to 4.3 because it caused
worse problems trying to use Java 8 JDK and after spending a full day
trying to track down the reasons I gave up.
On Mon, May 5, 2014 at 4:23 PM, Mahesh Gadgil <maheshgadgil(a)hotmail.com>wrote:
> I am using wrapper and version is 1.9.
> This problem was resolved when I upgraded to java 1.7.0_55.
>
> Thanks
> Mahesh
>
> ------------------------------
> Date: Sat, 3 May 2014 09:45:34 -0500
> Subject: Re: [hibernate-dev] Build failure executing
> :hibernate-core:runAnnotationProcessors
> From: steve(a)hibernate.org
> To: maheshgadgil(a)hotmail.com
> CC: hibernate-dev(a)lists.jboss.org
>
>
> Are you using a local Gradle install, or the Gradle Wrapper? If a local
> Gradle install, which version?
>
>
> On Wed, Apr 30, 2014 at 3:10 PM, Mahesh Gadgil <maheshgadgil(a)hotmail.com>wrote:
>
> I am facing the same issue Gale Badner mentioned in his email
> (hibernate-core:runAnnotationProcessors - BUILD FAILED) -
> Gail Badner Fri, 28 Mar 2014 16:35:18 -0700.
> but unlike him I am unable to resolve the issue. I am using java 1.7.0_51
> and tried to compile 4.3 branch.
>
> ThanksMahesh
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
12 years
Session.evict does not allow nulls after upgrade
by amit shah
We upgraded hibernate from 3.6.0 to 4.3.5 but the application fails if null
is passed to Session.evict()
The application passes null since the code is generic.
Are there any alternatives?
Thanks,
Amit.
12 years
Loggers and categories
by Steve Ebersole
Wanted to revisit something that's been bothering me ever since we moved to
JBoss Logging : the definition of loggers.
While I think we have always understood that there are really 2 different
audiences for log messages, I think I have come to have a more clear
understanding of what that means and its implications.
We have log messages intended for usage scenarios and log messages intended
for debugging scenarios. To me, the first groups is represented by the
JBoss Logging MessageLogger messages. The second group are the things we
simply "pass through" to the underlying log backend (trace, debug messages).
In both cases we currently use the name of the Class initiating the log
message as the "category name". While I think that is absolutely the
correct thing to do in the case of that second group, what about the first
group? For that first group I wonder if its better to have "logical
category names" more like 'org.hibernate.orm.deprecations' and
'org.hibernate.orm.mapping'... The idea being that its easier to switch
these grouped categories on/off.
12 years
Jandex, scanning and discovery
by Steve Ebersole
As Brett finishes up the "unified schema" work I wanted to start discussion
about some simplifications that could/should come from that.
Jandex, scanning and discovery
One of the outcomes of moving to Jandex to process annotations is the
requirement that we have a good Jandex Index available to us. There are 2
parts to this:
1. We need a "baseline Index". This can be a Jandex Index passed to us
(by WildFly, e.g.). But in cases where we are not passed one, we need to
build one.
2. We then augment the Index with "virtual annotations" built from XML
mappings.
As I said, in the cases we are not handed a Jandex Index we need to build
one. Currently this is a tedious process handled by manually indexing all
known classes (known from a few different sources). But this need to know
the classes to index them is problematic.
Which got me to thinking that it sure would be nice to tie this in to the
scanning (org.hibernate.jpa.boot.scan.spi.Scanner) stuff we do already such
that as we walk the "archive" we automatically add classes we encounter to
the Index. I'd actually add things to the Index whether or not they are
supposed to be managed classes (exclude-unlisted-classes).
There are lots of benefits to this. And not just to ORM, provided we start
sharing the Jandex with Search (etc) as we have discussed. This better
ensures that all needed classes are available in the Index. This allows
better discovery of "ancillary" classes via annotation. Etc...
Technically this one is not tied to the unified schema work, we could do
this change today. The difference is that the move to the unified schema
means that everything is processed using Jandex, so having that good Index
becomes even more important.
There is one difficulty I see here. Assuming we are to only use
listed-classes, that means classes explicitly listed in the PU *and*
classes listed in XML. Checking that a class is listed in the PU is
simple, but checking whether a class comes from XML before we use it is not
as straightforward. Its not impossible, just another thing to consider.
Applying XML defaults
orm.xsd allows specifying attribute specific defaults. One such default,
e.g., is access. What happens in the current annotation "mocking"[1] is
that the default access is only applied to attributes that are referenced
in the XML. If the XML is used in an "override" way and an attribute is
defined in the entity with annotations but is not mentioned in the XML, the
default access from the XML is not picked up, as it should be (unless the
annotations define a more local explicit access).
I think the solution is to expose all the 'persistence-unit-defaults'
values on the org.hibernate.metamodel.source.spi.MappingDefaults and grab
them from there.
-- seems to me there were others I wanted to discuss, but they escape my
mind at the moment ;)
[1] I think we all dislike the term "mocking" here. I'd like to start
discussing alternatives. I mentioned "augmentating" above, I like that
one.
12 years
