Re: [hibernate-dev] Hibernate Search: configure the LockingFactory
On Mon, 16 Feb 2009 15:06:27 +0100, Sanne Grinovero wrote: 1) property name: I'm naming the property key "locking_strategy", scoped for each DirectoryProvider. Is it really useful to be able to configure it per DirectoryProvider? How useful is it to mix the locking strategies between providers? I understand that from a consistency point of view it is the way to go. On the other hand by providing all these options you bet that people will start using "stupid" combinations. 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 What's about a approach similar to "Reader strategy configuration", where shared and not-shared are basically alias names for the underlying class names. This gives you names for the most common lock factories and you can plug your own strategy. And of course there is the consistency argument ;-) 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? If there is only one single Hibernate Search process running on the machine AND no other process using Lucene natively it should be ok. 4) default: 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. What are the problems? --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Search: configure the LockingFactory
2009/2/17 Hardy Ferentschik : > On Mon, 16 Feb 2009 15:06:27 +0100, Sanne Grinovero > wrote: > >> 1) property name: >> I'm naming the property key "locking_strategy", scoped for each >> DirectoryProvider. > > Is it really useful to be able to configure it per DirectoryProvider? How > useful is it > to mix the locking strategies between providers? > I understand that from a consistency point of view it is the way to go. On > the other hand > by providing all these options you bet that people will start using "stupid" > combinations. I'm not really worried about "stupid" combinations as different DPs are indipendent; somebody could use a RAM-DP for something and a FS-DP for something else, and maybe have one favourite on a NFS share.. for each one there are more suitable locking strategies. If you wanted to use only one strategy, then no code change is required as Lucene is reading a system property to define the implementation as you don't define one (and Search is not defining, so you could experiment with it without code changes); so this feature is really to provide the flexibility to have different ones per DP (and make is easy). >> 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 > > What's about a approach similar to "Reader strategy configuration", where > shared and not-shared are > basically alias names for the underlying class names. This gives you names > for the > most common lock factories and you can plug your own strategy. > And of course there is the consistency argument ;-) Yes that's what I am proposing, the four names above is my proposal of " simple name mapping to factories", to the implementations listed. > >> 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? > > If there is only one single Hibernate Search process running on the machine > AND > no other process using Lucene natively it should be ok. > >> 4) default: > >> 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. > > What are the problems? basically it looks like (IMHO) a bug in Lucene's implementation: it is trying to acquire the lock, if it's locked it tries again - only once - after a second, and then it raises a timeout exception if it fails again; even if the lock has been available most of the time between the two checks. I'll ask on lucene's forums if we could change that; anyway the current 2.4 implementation is not my favourite candidate for our "default" implementation; I'm still investigating if my stress test was actually a situation that's not occurring normally, we should have only one thread (the writer one) accessing the index, but only in the "one search instance per index" scenario. > > --Hardy > > Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Search: configure the LockingFactory
On Tue, 17 Feb 2009 10:23:28 +0100, Sanne Grinovero wrote: I'm not really worried about "stupid" combinations as different DPs are indipendent; somebody could use a RAM-DP for something and a FS-DP for something else, and maybe have one favourite on a NFS share.. for each one there are more suitable locking strategies. If you wanted to use only one strategy, then no code change is required as Lucene is reading a system property to define the implementation as you don't define one (and Search is not defining, so you could experiment with it without code changes); so this feature is really to provide the flexibility to have different ones per DP (and make is easy). Fair enough. basically it looks like (IMHO) a bug in Lucene's implementation: it is trying to acquire the lock, if it's locked it tries again - only once - after a second, and then it raises a timeout exception if it fails again; even if the lock has been available most of the time between the two checks. I'll ask on lucene's forums if we could change that; anyway the current 2.4 implementation is not my favourite candidate for our "default" implementation; I'm still investigating if my stress test was actually a situation that's not occurring normally, we should have only one thread (the writer one) accessing the index, but only in the "one In this case we should definitely stay with 'simple' for now. --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [Bean Validation] @Pattern
I had a lot of demands for regexp support and since there is a need
for string matching in the built-in constraints...
http://opensource.atlassian.com/projects/hibernate/browse/HV-121
I replaced the bitwise guru flags approach with an enum
@Pattern( regexp = ".*", flags = { Pattern.Flag.CANON_EQ })
String name;
/**
* The annotated String must match the following regular expression.
* The regular expression follows the Java regular expression conventions
* see {...@link java.util.regex.Pattern}.
*
* Accepts String.
*
* @author Emmanuel Bernard
*
*/
@Target({ METHOD, FIELD, ANNOTATION_TYPE })
@Retention(RUNTIME)
@Documented
public @interface Pattern {
/**
* regular expression to match
*/
String regexp();
/**
* Flags considered when resolving the regular expression
*/
Flag[] flags() default {};
/**
* error message template
*/
String message() default "{validator.past}";
/**
* groups the constraint belongs to
*/
Class[] groups() default { };
/**
* Possible Regexp flags
*/
public static enum Flag {
/**
* Enables Unix lines mode
* @see java.util.regex.Pattern#UNIX_LINES
*/
UNIX_LINES,
/**
* Enables case-insensitive matching
* @see java.util.regex.Pattern#CASE_INSENSITIVE
*/
CASE_INSENSITIVE,
/**
* Permits whitespace and comments in pattern
* @see java.util.regex.Pattern#COMMENTS
*/
COMMENTS,
/**
* Enables multiline mode
* @see java.util.regex.Pattern#MULTILINE
*/
MULTILINE,
/**
* Enables dotall mode
* @see java.util.regex.Pattern#DOTALL
*/
DOTALL,
/**
* Enables Unicode-aware case folding
* @see java.util.regex.Pattern#UNICODE_CASE
*/
UNICODE_CASE,
/**
* Enables canonical equivalence
* @see java.util.regex.Pattern#CANON_EQ
*/
CANON_EQ,
}
}
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] SessionImpl.list(CriteriaImpl criteria) returns an empty list when no implementors exist
We could perhaps log.warn like we do for HQL, but throwing an exception is not a good idea imo. - Steve Ebersole Project Lead http://hibernate.org st...@hibernate.org Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com steve.ebers...@jboss.com steve.ebers...@redhat.com On Sat, 2009-02-14 at 09:29 -0800, Kevin Wong wrote: > 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
Re: [hibernate-dev] SessionImpl.list(CriteriaImpl criteria) returns an empty list when no implementors exist
Hi Steve, thanks for the idea. Thoughts on returning null instead of an empty list to differentiate an unsuccessful query versus a successful query that returns no items. Kevin - Original Message - From: "Steve Ebersole" To: "Kevin Wong" Cc: hibernate-dev@lists.jboss.org Sent: Monday, February 16, 2009 7:18:23 AM GMT -08:00 US/Canada Pacific Subject: Re: [hibernate-dev] SessionImpl.list(CriteriaImpl criteria) returns an empty list when no implementors exist We could perhaps log.warn like we do for HQL, but throwing an exception is not a good idea imo. - Steve Ebersole Project Lead http://hibernate.org st...@hibernate.org Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com steve.ebers...@jboss.com steve.ebers...@redhat.com On Sat, 2009-02-14 at 09:29 -0800, Kevin Wong wrote: > 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
Re: [hibernate-dev] SessionImpl.list(CriteriaImpl criteria) returns an empty list when no implementors exist
first, I want you to understand that hql and criteria both support
polymorphic querying. In other words the thing from which you query
does not have to be mapped, and we will instead query from all entity
class which implement the named interface or extend from the named class
('from java.lang.Object' and 'from java.lang.Comparable' are both valid
queries).
So consider this just another restriction on the result set, find all
implementers of said interface/class.
Now, like I said I am fine with logging a warning in the case where you
try to query from a interface/class for which there are no entities
which are implementers. But treating this any differently than a query
which returns zero results for other reasons is not valid imo.
Note that if this is important enough of a distinction to you you can
always perform the checking yourself using
org.hibernate.engine.SessionFactoryImplementor#getImplementors
So that if I were to try 'from java.lang.Comparable', but
( ( SessionFactoryImplementor )
factory ).getImplementors( java.lang.Comparable.class ) returned an
empty array you'd have this situation about whcih you are concerned.
-
Steve Ebersole
Project Lead
http://hibernate.org
st...@hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebers...@jboss.com
steve.ebers...@redhat.com
On Tue, 2009-02-17 at 10:57 -0800, Kevin Wong wrote:
> Hi Steve, thanks for the idea. Thoughts on returning null instead of an empty
> list to differentiate an unsuccessful query versus a successful query that
> returns no items.
>
> Kevin
>
> - Original Message -
> From: "Steve Ebersole"
> To: "Kevin Wong"
> Cc: hibernate-dev@lists.jboss.org
> Sent: Monday, February 16, 2009 7:18:23 AM GMT -08:00 US/Canada Pacific
> Subject: Re: [hibernate-dev] SessionImpl.list(CriteriaImpl criteria) returns
> an empty list when no implementors exist
>
> We could perhaps log.warn like we do for HQL, but throwing an exception
> is not a good idea imo.
> -
>
> Steve Ebersole
> Project Lead
> http://hibernate.org
> st...@hibernate.org
>
> Principal Software Engineer
> JBoss, a division of Red Hat
> http://jboss.com
> http://redhat.com
> steve.ebers...@jboss.com
> steve.ebers...@redhat.com
>
>
> On Sat, 2009-02-14 at 09:29 -0800, Kevin Wong wrote:
> > 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] hibernate-tools JUnit template
Good evening Lords & Ladies: This is a simple .ftl template to generate a trivial JUnit test code. Any ideas & improvements are welcome ;) junit-tool.ftl Description: Binary data ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
