OGM: unimplemented InfinispanDialect.updateTuple() ?
by Cyrille Chépélov
Greetings,
I'm attempting to use Hibernate OGM with the Infinispan backend, using a
single FileCacheStore. I find the technology quite promising, and would
love to get this to run.
I'm running under Jetty, with the JbossTS.
I'm attempting something fairly simple so far:
DataGate.getTM().begin(); // returns the
JBossTSStandaloneTransactionManagerLookup().getTransactionManager(null);
EntityManager em = DataGate.createEntityManager(); // same...
try {
Document db_doc = em.find(Document.class, "12345"); //
nothing in so far.
db_doc = new Document(); // Document is a @Entity with @Id,
@GeneratorValue etc.
// set db_doc's properties
em.persist(db_doc);
} finally {
DataGate.getTM().commit();
em.close();
}
I can see some activity related to the JbossTS' XA manager (intent files
being created ...)
I can see Infinispan's FileCacheStore creating the empty cache
directories
I can see, upon commit, the transaction code decide to call things all
the way through OgmEntityPersister.execute() and
InfinispanDialect.updateTuple() (with a null original tuple cache entry,
which is okay since my database is empty).
I can see the transaction code declare the system happy and the
transaction complete, and proceed to delete the XA intent log.
What I never see, though, is any actual persistence for my data. Nor do
I see InfinispanDialect.updateTuple() somehow causing FileCacheStore's
updateBundle methods to run.
Is there something I'm missing ?
Thank you very much in advance.
-- Cyrille
PS:
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan</artifactId>
<version>5.0.0.FINAL</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.jboss.jbossts</groupId>
<artifactId>jbossjta</artifactId>
<version>4.15.3.Final</version>
<exclusions>
<exclusion>
<artifactId>jboss-logging-spi</artifactId>
<groupId>org.jboss.logging</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.hibernate.ogm</groupId>
<artifactId>hibernate-ogm-core</artifactId>
<version>3.0.0.Alpha2</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
12 years, 8 months
[Search] Sharding configured on types, not on indexes
by Sanne Grinovero
After more feedback about sharding from IRC and the forum [1], I
believe we should bind sharding implementations to indexed types, as
opposing to index names.
Currently a sharding strategy is strongly related to the index, but
configured on the index name and so it will affect all entities using
that same index name: there's no need to enforce this.
This also means we could change the sharding strategy interface to:
a - deal with Entity instances instead of org.apache.lucene.Document
and string-encoded ids
b - be a typesafe interface using generics
This would affect configuration: instead of configuring them on the
index name, an annotation should be placed on the type (or an optional
parameter for existing @Indexed).
So we won't be able to figure out in how many shards an index is
divided at boot time (unless we ask the sharding strategy via a new
method for this purpose), but this is good provided we finally support
dynamic sharding: start IndexManagers on demand as needed.
Configuration should have been reworked anyway, as it currently
supports only numbers as sub-indexes identifiers.
On top of a greater flexibility in sharding, but will also avoid
exposing the o.a.l.Document yet in another API. Not last, I've seen
cases in which people where forced to encode some token in the
Document only for the sake of their sharding strategy decision logic.
Sanne
1 - https://forum.hibernate.org/viewtopic.php?f=9&t=1011836
12 years, 8 months
new metamodel code
by Steve Ebersole
This follows up on a discussion from today's irc developer meeting, so
see notes for backstory
The new metamodel code is taking a lot longer than anticipated. Those
of us at the meeting agreed that we do not see it being finished in the
next 2-4 weeks which is kind of the outside edge I wanted to see for 4.0
so we will be dropping that work as milestone for the 4.0 release.
Which means we need to decide on how to move forward on 4.0. The
options brought up during the meeting include:
1) Just keep the Configuration and org.hibernate.mapping stuff in place
2) Use org.hibernate.metamodel.MetadataSources,
org.hibernate.metamodel.Metadata, etc but retrofit them to use
org.hibernate.mapping stuff
3) Just keep chugging with 4.0 and upstream projects (JBoss AS, for
example) will just need to use 3.6
Each of those have associated pros and cons (again see meeting minutes).
Lets meet up quickly tomorrow at same time as normal dev meeting and
vote on these and discuss other alternatives.
--
steve(a)hibernate.org
http://hibernate.org
12 years, 8 months
TypeDef annotation
by Dmitry Geraskov
Hey, guys,
I tried to find the requirements for
@TypeDef#typeClass class property. I thought it is neccessary that
typeClass be an implementation of org.hibernate.usertype.UserType
interface, but seems it is not true. Could you please help me with the
questions:
1. If typeClass should implement org.hibernate.usertype.UserType interface
2. Can it be a primitive type
3. Any other requirements
Or would be nice if you point me on some doc which describes al possible
usages of the annotation.
Thanks,
Dmitry Geraskov
12 years, 8 months
Build broken
by Hardy Ferentschik
Hi,
seems the build for Hibernate Core is broken at the moment. This is
related to the latest commit related to JPA callback methods -
adf627159447e872ad26
Looking into it. Probably best not to pull for now.
--Hardy
12 years, 8 months
Re: [hibernate-dev] Catering for a new index + writer/reader
by Hardy Ferentschik
On Fri, 12 Aug 2011 00:02:09 +0200, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
> I just read the document (nice doc! where did you find it?)
It was attached to the original Lucene issue related to faceting.
> The commit requirements of this taxonomy index look like a mess, and
> it also concerns me that it's totally impossible to remove stuff.
Yeah, there are quite some rules around when to commit in relation to
the main index writer. Good that there is Hibernate Search which can
handle this for the user :-)
Personally I am surprised that they introduced this new taxonomy index.
Funny enough the actual indexed Documents also contain category (faceting)
information. Hence also the need for the DocumentBuilder. I am sure that
there are good reasons to introduce this new index, but I am surprised
nevertheless.
> Yes generally the architecture supports it (as far as how we linked
> all components), but both the backend and the ReaderProvider would
> need a custom implementation; while it looks like the ReaderProvider
> needs an additional API method, I think we can avoid it on the
> backend.
I want to expose as little as possible of the underlying Lucene
functionality.
For power users we might want to offer some way to access the
TaxonomyIndex/Reader directly. Not sure yet.
We will also need to extend on the annotation side. Our approach allows to
facet on any un-tokenized field. In the Lucene case we need to know for
which
fields we have to create faceting information. We could do this with an
additional
optional parameter to @Field or we introduce a new @Faceted (or something
like this)
annotation. Obviously the Lucene goes a step further with category path
than our
current faceting approach, but we don't have to extend our faceting DSL
right
away.
> Also, so you know what kind of data structure expect TaxonomyWriter
> and TaxonomyReader? we'll need clustering for that too, hopefully it's
> similar to a Map, or reuses the Directory API.
For clustering purposes I think we have to look at CategoryPath and how to
serialize it. It should be just a bunch of strings, but I haven't seen the
code
yet.
It would have been nice to get this stuff into Search 4 as well, but of
course it
depends on when the next version of Lucene (either 3.4 or 4) would be
available.
A Hibernate Search 4 bundled w/ Hibernate Core 4 and Lucene 4 would have
been
cool, but I don't think the timing will work out :-)
--Hardy
> 2011/8/11 Hardy Ferentschik <hibernate(a)ferentschik.de>:
>> Hi,
>>
>> I was just reading the docs for the new Lucene faceting which makes use
>> of a new index called taxonomy index. If we are going to use Lucene
>> capabilities we have to make sure we can plug this into our current
>> architecture.
>>
>> Reading the docs I can see quite some similarities between our
>> terminology and theirs. That's good. However, the Lucene approach takes
>> it much further.
>>
>> We might get a new candidate for serialization as well - CategoryPath.
>>
>> I uploaded the faceting API documentation to our shared dropbox
>> directory. Have a look in case you are interested.
>>
>> --hardy
12 years, 8 months
