Re: [hibernate-dev] SessionImpl.list(CriteriaImpl criteria) returns an empty list when no implementors exist

[Max Rydahl Andersen]

you need to explain more specifically what you mean by "if the 
implementators exists" ?


i.e. an example.

/max

Hi all, in using hibernate v31final SessionImpl.list(CriteriaImpl criteria), I 
had an issue where hibernate would return an empty list when no implementors 
existed for the entity name(I had mistaken deleted the entity from the 
hibernation configuration file). The confusion arose in that this was be 
mistaken for a query that would return no rows. In looking at the code, it 
appears that the results list is always initialized to an empty list rather 
than null. Likewise, no exception is thrown if the entity does not exists, 
whereas when using HQL an org.hibernate.hql.ast.QuerySyntaxException exception 
would be thrown. Opinions on initializing the results list to null or throwing 
an exception if the implementators exist for the desired entity?

Thanks
Kevin
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
   


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search: configure the LockingFactory

[Sanne Grinovero]

Hi all,
to solve HSEARCH-284 (Lucene locks left around in application restart/crash)
I am investigating the differences in all Lucene's LockFactory implementations;
some of them are interesting and I would like to add a configuration option to
replace the default one in Hibernate Search.

1) property name:
I'm naming the property key "locking_strategy", scoped for each
DirectoryProvider.

2) values:
At first I was planning to use the usual design to be able to specify
any implementation
by specifying the qualified class name, but actually only 4
implementations make sense
and if someone really needed the flexibility to implement their own
they can define
their own DirectoryProvider and use whatever they want.
Also 2 of the base Lucene implementations are missing a public no-args
constructor,
so I would use only simple names:

simple -> org.apache.lucene.store.SimpleFSLockFactory
native  -> org.apache.lucene.store.NativeFSLockFactory
single  -> org.apache.lucene.store.SingleInstanceLockFactory
none   -> org.apache.lucene.store.NoLockFactory

3) support for "none":
I don't think we should let the user select something which is not compatible
with H.Searche's design, so I am still trying to figure out if the NoLockFactory
could be an option in case Search is the only process accessing the index.
Currently inside search the IndexReaders/Searchers are read-only, and at most
one IndexWriter is using the DP, so the locking strategy could be set
to "none" IMHO.
opinions?

4) default:
The current default is "simple", which has the problem as reported in
HSEARCH-284,
so I was puzzled by the idea to define the "native" as the default one to have
Search beginners avoid the locking problem, but I am hitting some
problems under load testing,
so I think the default should stay to "simple" at least for now.

Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev