[hibernate-dev] [ISPN-6] Documentation for Infinispan 2nd level cache provider available now online
Hi all, Re: http://www.jboss.org/community/wiki/UsingInfinispanasJPAHibernateSecondLevelCacheProvider Please find in the link above a wiki explaining how to configure Infinispan as a second level cache provider. The advanced configuration section is of particular interest for anyone who wants understand what's changed compared to JBC based cache providers and the advanced configuration options, such as Brian's eviction/expiration settings on a per entity/collection or Hibernate data type basis. Note that there's a few pieces of information missing, such as the Hibernate version from which this can be used and also the AS version that includes this. A javadoc link to next Hibernate 3.5 release or GA when it's ready would be helpful too. This has been linked from http://www.jboss.org/community/wiki/Infinispan too. Any feedback appreciated. Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Patch for HHH-272: Custom SQL for column gets and sets
1) Personally, I don't like the attribute names sql-get and sql-set. When I think through trying to describe and explain this feature to people, the terms wrap and unwrap keep coming to my head as being descriptive, relevant and natural. It was really the naturalness aspect that got me with sql-get and sql-set. Other terms I could think of included encode/decodeAny other suggestions? 2) Can anyone foresee a valid use-case for allowing one of these to be defined w/o the other? The only thing I came up with was for immutable properties. So something like column name=xyz unwrap=decode(xyz) insert=false update=false/, which can also be defined using a formula like formuladecode(xyz)/formula. The reason I ask is that if they should always be used together then maybe it is better to enforce that in the DTD and/or binder 3) You renamed the getTemplate method on Selectable to getGetterTemplate. Everything in the o.h.mapping package is an SPI that is used by many other libraries. We need to be very careful about changing stuff in here. I am not sure if folks bind to this particular method. But since this is just a cosmetic change, I think it should be reverted. Still not done looking through the whole patch. Will try to finish up tomorrow. On Wed, 2009-09-02 at 17:02 -0500, Steve Ebersole wrote: Awesome! This is one of those things I always wanted to get implemented but it was always getting pushed down my priority list. Thanks for taking on that work. I'll definitely take a look this week. If you could work it up for trunk that would be better. New features should really not get added to maintenance releases. On Wed, 2009-09-02 at 17:17 -0400, Rob Hasselbaum wrote: Hi, I've submitted a patch with unit tests for HHH-272 and I'm interested in feedback. The patch allows users to specify custom SQL get and set expressions for property columns. This can be used to call SQL functions or perform some other kind of database-side conversion without giving up automatic statement generation. You use it like this: property name=creditCardNumber column name=credit_card_num sql-set=encrypt(?) sql-get=decrypt(credit_card_num)/ /property This is similar to a formula property with two differences. First, the data is backed by a real column, which gets exported with the schema. And second. the data is read-write, not read-only. The sql-get expression gets applied in predicates, order clauses, projections, etc. The patch should work for all property columns including those in components and composite-elements. I didn't try to get id, key, index, or other kinds of non-property columns to work. It is built on top of the 3.3.2.GA tag, but I can port it to trunk if necessary. I also have a patch nearly ready to expose this functionality in Hibernate Annotations in case the Core patch is accepted. If any commiters could have a look, I'd appreciate it. Thanks for your time, -Rob Hasselbaum ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Steve Ebersole st...@hibernate.org Hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [HibernateSearch] Infinispan programmatic configuration
I am thinking how to provide programmatic configuration into Hibernate
Search for many caches, i.e. if user wants to use different configured
caches for each index.With XML it is ok, in one file can be configured many
named caches. So far in programmatic version user have to implement method
that returns Configuration object - only one configuration can be provided
that way.
To achieve this same what in XML case, method should return something like:
List{cacheName}, {configuration}. It is quite painfull, but on the other
hand just extra feature. Some other ideas?
Cheers,
Lukasz Moren
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [HSearch] DSL for Lucene queries (was: Re: Query module new API and configurations)
On 28 août 09, at 07:54, Sanne Grinovero wrote: Sure I like it! I'm in the swamp of old mails, so I give you my first impression only: Even if it's fluent it's not (yet) intuitive to me which methods I should call; Query luceneQuery = qb.must(Occurs.MUST) .add( qb.boolean(Occurs.Should) .add( qb.term(city, Atlanta).boostedTo(4).createQuery() ) .add( qb.term(address1, Peachtree).fuzzy().createQuery() ) ) .add( qb.from(movingDate, 200604).to(201201).exclusive().createQuery() ) .createQuery(); I guess there is a typo? As must(MUST) is a bit confusing to me. yep typo. why not qb.booleanQuery() .Must( qb.otherQuery(...).. ) .Should( qb.secondQuery(..).. ) .build(); good idea, .must() .add( qb.from().to() ) .add( ... ) .must().not() .should() and qb.termQuery(city, Atlanta).boostedTo(4).createQuery()) or even overloading qb.termQuery(city, Atlanta).createQuery()) with qb.termQuery(city, Atlanta, 4f).createQuery()) is not as readable as boostedTo method but more immediate; intelligent IDEs should propose the options to devs while typing, even guessing the parameter name and making it's meaning self-evident. No I find it hard and confusing even in IntelliJ IDEA to use overloaded methods and a set of parameters. The idea behing boostedTo() is to mimick named parameters. Actually ideally we would want term().on(city).matches(Atlanta), WDYT? Or even qb.on(city).matches(atlanta) which could also be used to unify range queries and multi term queries qb.on(date).from(2009).to(2010) qb.on(a).on(b).matches(word) qb.rangeQuery could be either rangeQuery(field, fromX, toY) or rangeQuery(field).from(x).to(y) so why are you choosing (field,from).to(to) ? I think range(field).from(x).to(y) or on(field).from(x).to(y) are better, I've move to range and if we decide on is better, I will move. Thinking about the RangeQuery on dates, it would be cool to accept any type for which we have Bridges, like accepting Date type or even a user-defined FieldBridge together with an Object. That would be cool but realistically we need to accept Object unless somehow we can convey the expected type(s) of a field bridge using generics or something. SOmebody has an idea on how the API would look like? probably something like T on(String field, ClassT) ... on(field, Date.class).from(new Date()). I like the Analyzer choices, it would be very cool if we could by default guess the correct one from the searched-for entity types. Define guessing. Guessing the targeted entity? How? We could even consider a Query-By-Example query builder, reading indexed fields from an instance of an indexed type, or something like HSEARCH-119 proposal (for termvectors similatory). +1 but let's start (not so) modest :) cheers, Sanne 2009/8/28 Emmanuel Bernard emman...@hibernate.org: Hey Sanne, What do you think of the PAI proposal itself? Like it? See improvements? On 28 août 09, at 10:37, Sanne Grinovero wrote: I've nothing against a separate maven module, still Hibernate Search already has lots of goodies to work with Lucene which are not necessarily linked to Hibernate (e.g. Analyzer definition helpers, pojo mapping through annotations, enhanced filtering, IndexReader pooling, nice Infinispan Directory...) so this new query builder is not much different. Just a thought. So even if Emmanuel has shown this builder to be useful even with this limited features, it could become even more useful when strongly combined with the other features; 2 come to mind, may be more later: A) adding filters to the builders; I don't think it would be easy to have named filters without the full Search package B) Letting the users forget about the Analyzer matches complexity (optionally), as by using the mapping information we could default to a reasonable Analyzer for each field. Most users on the forum are in trouble because they select the wrong analyzer/ forget to use one when building the F.T.Query. IMHO these are good reasons to couple it to the rest of the code; Maybe it would be possible in future to have Hibernate optional. Sanne 2009/8/27 Manik Surtani ma...@jboss.org: On 27 Aug 2009, at 16:10, Emmanuel Bernard wrote: queryBuilder.withAnalyzer(Analyzer) queryBuilder.withEntityAnalyzer(Class?) queryBuilder.basedOnEntityAnalyzer(Class?) .overridesForField(String field, Analyzer) .overridesForField(String field, Analyzer) .build() //sucky name Perhaps rename the static factory methods to something like: QueryBuilder.getQueryBuilder(Analyzer) QueryBuilder.getQueryBuilder(Class?) and QueryBuilder instances have overrideAnalyzerForField(String, Analyzer). Why do you need the build() method at the end? if you do that, all of the sudden, a QB can change it's analyzer on the fly making it immutable.
Re: [hibernate-dev] [infinispan-dev] [HSearch] DSL for Lucene queries (was: Re: Query module new API and configurations)
answers and ideas inline: 2009/9/3 Emmanuel Bernard emman...@hibernate.org: On 28 août 09, at 07:54, Sanne Grinovero wrote: Sure I like it! I'm in the swamp of old mails, so I give you my first impression only: Even if it's fluent it's not (yet) intuitive to me which methods I should call; Query luceneQuery = qb.must(Occurs.MUST) .add( qb.boolean(Occurs.Should) .add( qb.term(city, Atlanta).boostedTo(4).createQuery() ) .add( qb.term(address1, Peachtree).fuzzy().createQuery() ) ) .add( qb.from(movingDate, 200604).to(201201).exclusive().createQuery() ) .createQuery(); I guess there is a typo? As must(MUST) is a bit confusing to me. yep typo. why not qb.booleanQuery() .Must( qb.otherQuery(...).. ) .Should( qb.secondQuery(..).. ) .build(); good idea, .must() .add( qb.from().to() ) .add( ... ) .must().not() .should() and qb.termQuery(city, Atlanta).boostedTo(4).createQuery()) or even overloading qb.termQuery(city, Atlanta).createQuery()) with qb.termQuery(city, Atlanta, 4f).createQuery()) is not as readable as boostedTo method but more immediate; intelligent IDEs should propose the options to devs while typing, even guessing the parameter name and making it's meaning self-evident. No I find it hard and confusing even in IntelliJ IDEA to use overloaded methods and a set of parameters. The idea behing boostedTo() is to mimick named parameters. Actually ideally we would want term().on(city).matches(Atlanta), WDYT? Or even qb.on(city).matches(atlanta) yes much better which could also be used to unify range queries and multi term queries qb.on(date).from(2009).to(2010) nice qb.on(a).on(b).matches(word) this is not really fluent, I only understand what you mean because of your comment qb.rangeQuery could be either rangeQuery(field, fromX, toY) or rangeQuery(field).from(x).to(y) so why are you choosing (field,from).to(to) ? I think range(field).from(x).to(y) or on(field).from(x).to(y) are better, I've move to range and if we decide on is better, I will move. I agree with your choice Thinking about the RangeQuery on dates, it would be cool to accept any type for which we have Bridges, like accepting Date type or even a user-defined FieldBridge together with an Object. That would be cool but realistically we need to accept Object unless somehow we can convey the expected type(s) of a field bridge using generics or something. SOmebody has an idea on how the API would look like? probably something like T on(String field, ClassT) ... on(field, Date.class).from(new Date()). I didn't mean that the method signature should be aware of the type, Object is fine; from( Object lowerBoundary ); //automatically finds out the StringBridge from the BridgeFactory from( Object lowerBoundary, StringBridge ); //overrides ths StringBridge selection Even better making StringBridge generic we get typesafety: T void from(T lowerBoundary, StringBridgeT bridge) I like the Analyzer choices, it would be very cool if we could by default guess the correct one from the searched-for entity types. Define guessing. Guessing the targeted entity? How? Ha right; I was assuming you were going to select the targeted entity, like with Criteria? We could even consider a Query-By-Example query builder, reading indexed fields from an instance of an indexed type, or something like HSEARCH-119 proposal (for termvectors similatory). +1 but let's start (not so) modest :) cheers, Sanne 2009/8/28 Emmanuel Bernard emman...@hibernate.org: Hey Sanne, What do you think of the PAI proposal itself? Like it? See improvements? On 28 août 09, at 10:37, Sanne Grinovero wrote: I've nothing against a separate maven module, still Hibernate Search already has lots of goodies to work with Lucene which are not necessarily linked to Hibernate (e.g. Analyzer definition helpers, pojo mapping through annotations, enhanced filtering, IndexReader pooling, nice Infinispan Directory...) so this new query builder is not much different. Just a thought. So even if Emmanuel has shown this builder to be useful even with this limited features, it could become even more useful when strongly combined with the other features; 2 come to mind, may be more later: A) adding filters to the builders; I don't think it would be easy to have named filters without the full Search package B) Letting the users forget about the Analyzer matches complexity (optionally), as by using the mapping information we could default to a reasonable Analyzer for each field. Most users on the forum are in trouble because they select the wrong analyzer/ forget to use one when building the F.T.Query. IMHO these are good reasons to couple it to the rest of the code; Maybe it would be possible in future to have Hibernate optional. Sanne 2009/8/27 Manik Surtani ma...@jboss.org: On 27 Aug 2009, at 16:10, Emmanuel Bernard wrote:
Re: [hibernate-dev] [infinispan-dev] [HSearch] DSL for Lucene queries (was: Re: Query module new API and configurations)
I don't see how people would nicely have access to the right bridge implementation On 3 sept. 09, at 17:30, Sanne Grinovero wrote: That would be cool but realistically we need to accept Object unless somehow we can convey the expected type(s) of a field bridge using generics or something. SOmebody has an idea on how the API would look like? probably something like T on(String field, ClassT) ... on(field, Date.class).from(new Date()). I didn't mean that the method signature should be aware of the type, Object is fine; from( Object lowerBoundary ); //automatically finds out the StringBridge from the BridgeFactory from( Object lowerBoundary, StringBridge ); //overrides ths StringBridge selection Even better making StringBridge generic we get typesafety: T void from(T lowerBoundary, StringBridgeT bridge) ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Patch for HHH-272: Custom SQL for column gets and sets
Hi Steve, Thanks for the feedback. I am working on moving the patch to trunk as you requested. I'll update the bug when that's done. My comments on the rest of your feedback are inline below. On 09/03/2009 04:39 PM, Steve Ebersole wrote: 1) Personally, I don't like the attribute names sql-get and sql-set. When I think through trying to describe and explain this feature to people, the terms wrap and unwrap keep coming to my head as being descriptive, relevant and natural. It was really the naturalness aspect that got me with sql-get and sql-set. Other terms I could think of included encode/decodeAny other suggestions? I went with sql-set and sql-get because they are consistent with the existing sql-type attribute and make sense to me, but I'm not married to the terms. Wrap and unwrap sound good, too. Bear in mind that the expressions need not be function calls, which wrap and unwrap might suggest. The functional tests do math, for instance. 2) Can anyone foresee a valid use-case for allowing one of these to be defined w/o the other? The only thing I came up with was for immutable properties. So something like column name=xyz unwrap=decode(xyz) insert=false update=false/, which can also be defined using a formula like formuladecode(xyz)/formula. The reason I ask is that if they should always be used together then maybe it is better to enforce that in the DTD and/or binder I couldn't think of a use case for a one-way conversion either. In fact, you could end up reading out a different value than the one you put in if you're not careful. But I'd regret adding an artificial restriction if someone came up with a legitimate use case next year. 3) You renamed the getTemplate method on Selectable to getGetterTemplate. Everything in the o.h.mapping package is an SPI that is used by many other libraries. We need to be very careful about changing stuff in here. I am not sure if folks bind to this particular method. But since this is just a cosmetic change, I think it should be reverted. Sorry, this was an oversight. At first, I thought I was going to need to store a setter template in addition to a getter template in the Column class, It turned out that I didn't need it, but I forgot to revert the name of the getter template. I'll fix that. Still not done looking through the whole patch. Will try to finish up tomorrow. Thanks, -Rob ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
