Developing ogm over MongoDB
by ildella＠gmail.com
Hi everyone.
I was talking with sanne about some scenario where I'd like to use
Hibernate Search to have a lucene index created with the HS ease of
use, and also to persist data over MongoDB, for the schema less
freedom and other reasons.
Scenario is I need to staret developing a new app with a simple domain
(collection of Companies with a set of ServiceRegistration each). I'd
like to wrap the mongoDB persistence layer like you did for
Infinispan, does that make sense?
My target is to make crud operation works with the KS nomenclature
(DBObject and Collection to start), and then to make HSearch work with
that (the real hard task).
I am a little lost in the ogm project, where should I start to watch
to find some tests that can drive my implementation?
Thanks for help.
--
Daniele Dellafiore
http://danieledellafiore.net
13 years, 9 months
Please commit the HHH-5842 patch
by Fred Toussi
This patch adds a BINARY type size parameter currently missing from the
HSQLDB dialect and affecting the latest HSQLDB versions with Hibernate
3.6.0 final.
Fred
13 years, 9 months
NullPointerException in SettingsFactory#buildSettings() when database not available in 3.6.FINAL
by jan zelenka
Hi,
In above mention method there is a protection against dead database and
dialect is build via
dialect = DialectFactory.buildDialect( props );
when exception is thrown from line
Connection conn = connections.getConnection();
e.g. when database is not available.
However there is no such protection when exception is thrown later from line
DatabaseMetaData meta = conn.getMetaData();
which is in inner try-catch block (code does not hit
any DialectFactory.buildDialect( props ); then)
This can happen for certain connection pools (atomikos in my case).
Subsequently, NullPointerException on line 169 is hit.
I think call to DialectFactory.buildDialect( props ) also in inner catch
block on line 140 would solve it nicelly.
Thanks,
Jan
13 years, 9 months
Re: [hibernate-dev] Have Infinispan share Hibernate's TransactionManagerLookup strategy
by Emmanuel Bernard
Any particular reason why you target ISPN 5.0 and not 4.2?
I don't think we can ask Hibernate Core (and hence OGM) to rely on 5.0 yet.
On 1 févr. 2011, at 20:12, Sanne Grinovero wrote:
> As discussed, I have been playing with Infinispan's configuration
> options to have it startup using hibernate's TransactionManagerLookup.
> It wasn't working initially because of ISPN-883, but this is now
> solved (thanks Mircea!).
>
> I'm not sure yet if this should be pushed to Hibernate Search, but it
> might be useful to have a look for OGM:
>
> https://github.com/Sanne/hibernate-search/commits/InfinispanTransactionMa...
>
> it's quite verbose, if you have suggestions I can try pushing some of
> the complexity into Infinispan, assuming they are fine with it.
>
> Sanne
13 years, 9 months
HSEARCH-471 Ability to selectively index an entity based on its state
by Emmanuel Bernard
Maybe it's time to revive this one since we have started to go down the rabbit hole with indexing only when dirty searched properties are present.
Begin forwarded message:
> From: "lantz moore (JIRA)" <noreply(a)atlassian.com>
> Date: 14 janvier 2011 01:52:05 HNEC
> To: emmanuel(a)hibernate.org
> Subject: [Hibernate-JIRA] Commented: (HSEARCH-471) Ability to selectively index an entity based on its state
>
>
> Issue (View Online)
> Key: HSEARCH-471
> Issue Type: New Feature
> Status: Open
> Priority: Minor
> Assignee: Unassigned
> Reporter: Dobes Vandermeer
>
> Operations
> View all
> View comments
> View history
> Ability to selectively index an entity based on its state
> Updated: 13/Jan/11 6:51 PM Created: 16/Mar/10 12:10 PM
>
> The following comment has been added to this issue: [ Permalink ]
> Author: lantz moore
> Date: 13/Jan/11 6:51 PM
> Comment:
> up until some recent restructuring of FullTextIndexEventListener and EventSourceTransactionContext i was able to implement something like this very easily.
>
> first, my use case: we have a few objects that are expensive to index but are modified "a lot". we only want them indexed at a few well defined transitions: initial creation and when certain members are modified. otherwise, we don't need them to be reindexed.
>
> to solve this issue with earlier versions of hib-search, we extended FullTextIndexEventListener and overrode processWork. we map classes to MVEL expressions and use the MVEL expressions to evaluate whether or not to index the entity.
>
> we define the FullTextIndexEventListener in spring and configure it like:
>
> <bean id="fullTextIndexer" class="com.example.dao.hibernate.FullTextIndexEventListener">
> <property name="entityChecks">
> <map>
> <entry key="com.example.model.RetailTransaction">
> <value>
> if (event is org.hibernate.event.PostUpdateEvent) { return (oldState.suspended != newState.suspended || entity.getTransactionState().name() != "PENDING") }
> return true;
> </value>
> </entry>
> </map>
> </property>
> </bean>
>
> then instead of autoregistering the default listeners, we register this new listener with the appropriate events. for our particular use case this helped us out quite a bit.
>
> however, it looks as though we aren't going to be able to do this in the near future because of the redesign of EventSourceTransactionContext and FullTextIndexEventListener.
>
> EventSourceTransactionContext.getIndexWorkFlushEventListener looks thru the listeners for the FullTextIndexEventListener like so:
>
> for (FlushEventListener listener : flushEventListeners) {
> if ( listener.getClass().equals( FullTextIndexEventListener.class ) ) { return (FullTextIndexEventListener) listener; }
> }
>
> which means our subclass of FTIEL isn't be found. plus, it looks as though FTIEL will soon be final.
>
> so, i don't know if we've been "abusing" the system here, or what, but this seemed like a fairly straight forward way of implementing conditional indexing and has worked really well for us for quite some time.
>
> i'm not suggesting that hib-search make a dependency on MVEL, etc; however, it would be nice if we were able to continue to subclass FullTextIndexEventListener in the way that we have been.
>
>
> Project: Hibernate Search
> Components: mapping
> Affects Versions: 3.1.1.GA
> Fix Versions: 3.4.0
>
> Description
> In our system we have entities that are searched but not all of them are available for search - some of them are flagged as "removed". It would improve the efficiency of our search subsystem if we could implement a kind of "filter" that blocked these entities from being added to the search index, since we wouldn't have to make that a search term and our indexes would be somewhat smaller.
>
>
> This message was automatically generated by Atlassian JIRA Enterprise Edition, Version: 4.1-519 - Bug/feature request.
> If you think it was sent incorrectly, contact one of this server's administrators.
13 years, 9 months
