Patch for HHH-272: Custom SQL for column gets and sets
by Rob Hasselbaum
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
14 years, 7 months
Re: [hibernate-dev] Hibernate 3.5.0.Beta-1 released
by Alex Miller
As another Hibernate cache provider also aiming to be "the best Hibernate second level cache provider" out there, I would be a bit upset by having one anointed in the code as the default. Thank you Steve and Emmanuel for being the voice of reason.
Alex Miller
Terracotta/Ehcache
On 09/09/2009 17:35 PM, Galder Zamarreno wrote:
>
> Steve, taking in account that at least in the community version you ship
> a few different cache providers (correct me if I'm wrong), what about
> putting something in the Hibernate docs where you recommend using
> Infinispan? i.e. "Infinispan is the recommended 2LC provider"
>
14 years, 7 months
Re: [hibernate-dev] [infinispan-dev] [HSearch] DSL for Lucene queries (was: Re: Query module new API and configurations)
by Sanne Grinovero
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.
why not
qb.booleanQuery()
.Must( qb.otherQuery(...).. )
.Should( qb.secondQuery(..).. )
.build();
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.
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") ?
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.
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.
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).
cheers,
Sanne
2009/8/28 Emmanuel Bernard <emmanuel(a)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 <manik(a)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.
>>> Also the overridesForField methods would pollute the API when it's time
>>> to
>>> create a query.
>>> One of the advantages of a fluent API in a strongly typed environment is
>>> that we can hide methods that are meaningless in a given context.
>>>
>>> That been said, if the API ends up being pure Lucene and once we
>>> stabilize
>>> it, we can contribute it back even though I am not necessarily a huge fan
>>> of
>>> ASL.
>>>
>>> Not it doesn't have to be either ASL or even hosted at Apache. I guess
>>> what
>>> I am suggesting is perhaps even a separate project - LuceneQueryBuilder
>>> or
>>> something - which plain-old-Lucene users could use as well. Doesn't
>>> matter
>>> where it's hosted or what the license is - as long as its ASL or LGPL :)
>>>
>>> Let's start it under the Hibernate Search umbrella due to potential
>>> synergies and spin it out if needed.
>>>
>>> Ok. Just make sure we use a different maven module or something so that
>>> there are no dependencies on the rest of HS or Hibernate. Otherwise
>>> spinning out will be a PITA. Lucene should be the only dependencies of
>>> this
>>> code.
>>> Cheers
>>> --
>>> Manik Surtani
>>> manik(a)jboss.org
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>
>
14 years, 7 months
Infinispan QueryFactory API and lazy class addition into lucene
by Navin Surtani
Hello guys,
Was talking with Galder on Friday about how we were to implement the
new QueryFactory API into Infinispan. A main issue was how we could
pass the classes to Hibernate Search. It's currently done in the
SearchableCacheFactory upon creation of the SearchableCache.
We were wondering if it's possible to give the classes to Hibernate
Search lazily? So for example, is there a way to give the class to a
SearchFactoryImplementor when that type is added into the Cache for
the first time?
Also - if it's not possible, is there a feasible way for us to build
this into Hibernate Search? Maybe just create a new instance of the
SearchFactoryImplementor (assuming this won't throw away a lot of the
data required for lucene etc)?
Danke,
Navin Surtani
Intern Infinispan
Intern JBoss Cache Searchable
14 years, 7 months
[HibernateSearch] Infinispan programmatic configuration
by Łukasz Moreń
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
14 years, 7 months
[ISPN-6] Switch to distribution for default entity/collection cache?
by Galder Zamarreno
Hi,
While working on documenting the Infinispan cache provider, I've been
thinking on the default cache settings for each Hibernate type:
- Entity/Collection: Bearing in mind the requirement to keep this cache
synchronous, in the past we've gone for invalidation rather than
replication because using replication could mean having to replicate a
lot of data to all nodes in the cluster. For Infinispan however, I was
thinking of the possibility of making sync distribution default for
entities though since we are not replicating to everyone any more.
One doubt I have about here is how much of an advantage would be to
bring an entity from another node in the cluster if present
(distribution) vs loading it from the database if not available in the
local cache (invalidation).
The one downside I see of distribution vs invalidation is that if an
entity is not available locally and is not available in the cluster,
distribution is more expensive that invalidation, since dist involves
round trip in cluster and round trip to database, vs round trip to
database with invalidation.
However, unless eviction kicks in, this should only affect the 1st time
an entity/collection is queried cos the next time, it will be
distributed already and potentially in the L1 of the node that requested
it if it's not one of the owners.
So, I think I would make distribution default for entity/collection.
Thoughts? I'd still leave an invalidated configuration in the default
config file so that people can potentially swap to it if they want to.
- Query: I think we should stick to same JBC2/3 default here which is
local.
- Timestamps: Given the chattiness of this cache, and the low size
payloads, asynchronous replication still looks to me like a good default
for this cache.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 7 months
