OGM 5 Bootstrap: Reading property value in MetadataBuilderContributor
by Gunnar Morling
Steve, all,
For migrating OGM to the new ORM 5 bootstrap APIs, I am looking into using
a MetadataBuilderContributor for applying an OGM-specific
ImplicitNamingStrategy.
Provided it is exposed via META-INF/services, the contributor is run
un-conditionally. So I'd need a way to find out whether the passed
MetadataBuilder is meant to bootstrap Hibernate ORM or OGM.
If there is no way to do so (I couldn't find any), could the previously
applied configuration settings be exposed e.g. via
* an accessor MetadataBuilder#getSettings()
* or a new parameter on
MetadataBuilderContributor#contribute(MetadataBuilder b, Map<String,
Object> settings)
* or even MetadataBuilderContributor#contribute(MetadataBuilder b,
StandardServiceRegistry ssr)
?
Then I could make contribute() instantly return depending on some property
which is set before (we can do that for JPA in HibernateOgmPersistence,
OGM's PersistenceProvider, and in a custom ServiceRegistry factory for
non-JPA).
Thanks,
--Gunnar
10 years, 8 months
OGM cassandra backend
by Jonathan Halliday
The first part of the cassandra backend work is ready for review. I've
backed out the incomplete association support, leaving the basic
framework for the backend module with enough functionality to support
entities that don't have relations. It's still larger than an average
PR, but the module design follows an established pattern so it shouldn't
cause too much problem.
Unfortunately the plugin that runs cassandra embedded is a bit stale and
won't play nice with the newer cassandra release that is required for
some bug fixes. Until it catches up, you (and the CI cluster) will need
to bring up a db server manually before running the tests. Fortunately
it's not hard:
http://www.apache.org/dyn/closer.cgi?path=/cassandra/2.1.4/apache-cassand...
untar, then run bin/cassandra -f
I has intended to roll straight into the association support
functionality whist the PR on this first part was being reviewed, but I
think I'll context switch to some infinispan stuff and return to OGM
aligned with the next sprint starting in a couple of weeks.
Jonathan.
--
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)
10 years, 8 months
JSR107 H2LC module
by Alex Snaps
Hey guys,
I'm not completely, only mostly, done with the JSR-107, aka javax.cache,
aka jcache, 2nd level cache for Hibernate.
I still have to sort out the issue with dependencies, where the current
hibernate-ehcache module suffers from the new module being added (I use
ehcache as the provider for testing); and finish the integration with the
hibernate-orm cache test module. I hope to finish these off within the
coming week.
That being said, I thought I'd share it already, as I'm seeking input on it
from other caching modules (i.e. infinispan mainly I guess)... So maybe
Sanne or someone may be able to find some time to do a "conceptual" review.
I'm trying to hangout on IRC more often now, so feel free to call me out on
there...
Anyways, rfc! I hope this can make sense for others...
Let me know what you think. It's all on my github fork in the
hibernate-jcache module:
https://github.com/alexsnaps/hibernate-orm/tree/jsr107
Alex
10 years, 8 months
javac -source and -target
by Steve Ebersole
Is there ever a time *in out projects* where we would want the -source and
-target to name different versions?
I think generally speaking I cannot see a practical reason for this, and we
don't allow that anyway today (in ORM anyway).
10 years, 8 months
ORM 5.0 and IntelliJ
by Steve Ebersole
Another change with master is that IntelliJ import finally works as far as
properly setting up excludes in IntelliJ to not "hide" generated-src. The
fact that generated-src is under the $buildDir makes this more complicated
than it need to be, but it works.
There is currently a minor issue with IntelliJ import in ORM master that I
have not yet investigated. It has to do with attempting to set different
"jdkName" for the hibernate-java8 module. I reported an issue with
IntelliJ, but then it seems to work from my standalone gradle-mixed-jdk
project[1]
Anyway, just a heads up..
[1] - https://github.com/sebersole/gradle-mixed-jdk
10 years, 8 months
Transaction
by Steve Ebersole
I thought I had asked this before, but maybe not. Andrea and I are working
through the transaction/jdbc changes and I really would like to clean up
the org.hibernate.Transaction API. But before I start cutting I wanted to
make sure noone is using the methods I plan on getting rid of...
Here is the new proposed contract:
public interface Transsaction {
public void begin();
public void commit();
public void rollback();
public void markRollbackOnly();
public Status getStatus();
public int getTimeout();
public void setTimeout(int seconds);
public void registerSynchronization(Synchronization synchronization);
}
public enum Status {
NOT_ACTIVE,
ACTIVE,
COMMITTED,
ROLLED_BACK,
FAILED_COMMIT
}
Notes:
1) isInitiator() has been removed with no real replacement. I could not
really see when that would be useful.
2) isParticipating() has been removed with no real replacement.
2) isActive(), wasCommitted() and wasRolledBack has all been removed with
call to getStatus() as replacement
3) getLocalStatus() is gone. Who cares :) If users are asking us this, we
really should be checking the REAL state of the transaction
4) Transaction is now a single impl. The distinctions are all handled
internally. TransactionImplementor is gone too.
Thoughts? Concerns?
10 years, 8 months
Java 6, 7 and 8... oh my!
by Steve Ebersole
So we now have to deal with a multi-jdk build in Hibernate ORM. We need
Java 8 in order to compile the new hibernate-java8 module.
I wanted to remain compatible with Java 6 for the rest. However, I ran
into a snag there because of JAXB which we now use (in conjunction with
StAX) to process XML in ORM. ANyway, the JAX generation creates a model
that is only compatible with Java 7. I have not yet had time to
investigate this deeply. But it has to do with a change in the definition
of javax.xml.bind.annotation.XmlElement and a change in its definition
between 1.6 and 1.7 to add a new
attribute javax.xml.bind.annotation.XmlElement#required.
If anyone is familiar with this situation, I'd love to hear some options
before I spend a lot of time investigating it.
The other option is that we say we are going to drop Java 6 support since
it has been unsupported now for, what, 3 years?
10 years, 8 months
Trying Hibernate 5.0.0.Beta1
by Petar Tahchiev
Hi guys,
I just tried the latest beta and I cannot compile my project. With the
latest hibernate 4.3.X I was able to do this:
-------
final org.hibernate.cfg.Configuration configuration =
getHibernateConfiguration();
configuration.buildMappings();
final SchemaUpdate schemaUpdate = new SchemaUpdate(configuration);
-------
however it seems that the SchemaUpdate constructor has been removed and now
a new one is added:
--------
public SchemaUpdate(MetadataImplementor metadata) {
this( metadata.getMetadataBuildingOptions().getServiceRegistry(),
metadata );
}
---------
Also the configuration.buildMappings() method has been deprecated. Where do
I get the MetadataImplementor from? Also is there any changelog I can refer
to?
Thanks.
--
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
10 years, 8 months
document update change?
by Ales Justin
Did entity updating changed in HS5 / Lucene4?
(aka Document updating)
Since this used to work for us (with HS4, Lucene3):
---
@Test
public void testProjectionQueriesHandleEntityModificationProperly() throws Exception {
Entity e = createEntity("test", 1)
.withProperty("prop", Arrays.asList("aaa", "bbb", "ccc"))
.store();
Query query = new Query("test")
.addProjection(new PropertyProjection("prop", String.class))
.addSort("prop");
assertEquals(3, service.prepare(query).asList(withDefaults()).size());
e = createEntity(e.getKey())
.withProperty("prop", Arrays.asList("aaa", "bbb"))
.store();
assertEquals(2, service.prepare(query).asList(withDefaults()).size());
service.delete(e.getKey());
assertEquals(0, service.prepare(query).asList(withDefaults()).size());
}
---
Where we add each list/collection value under same field:
if (propertyValue instanceof Collection) {
Collection collection = (Collection) propertyValue;
for (Object element : collection) {
if (PropertyUtils.isIndexedProperty(element)) {
final Bridge inner = BridgeUtils.matchBridge(element);
luceneOptions.addFieldToDocument(propertyName, inner.objectToString(element), document);
}
}
---
As it looks like the update still keeps the old values around:
java.lang.AssertionError: expected:<2> but was:<3>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at org.jboss.test.capedwarf.datastore.test.QueryOptimizationsTest.testProjectionQueriesHandleEntityModificationProperly(QueryOptimizationsTest.java:510)
---
Any way to force / fix this?
-Ales
10 years, 8 months
