[infinispan-dev] Flexible indexing - an idea

[Emmanuel Bernard]

Question.
Why don't you create a MP3 file and populate it with your metadata and  
the byte[] before putting it in the cache?
ie your app is responsible for POJOifying a MP3. Everything's a POJO  
or is lame these days.

If I understand your idea though, I think it could have merit, to do  
this transformation internally in HSearch or JBoss Cache, ie to make.  
But it has some drawbacks:
  - it must be 100% API transparent to the user otherwise that's hacky
  - by hiding the POJO aspect, you hide the fields a user can query.  
It has to read your doc or check this interception layer to find out  
that MP3 has a bpm field

Emmanuel

On 29 sept. 09, at 09:50, Michael Neale wrote:

> Hi All.
>
> I have been looking over the Infinispan query module by Navin.
>
> As this is built on Hibernate Search - (and correct me if wrong) the
> indexing happens on pojos fields.
> This is great for most of the cases, but for my ulterior motive (which
> I will reveal in another email) I would like to deal with certain
> object types differently. So lets for instance take a media file like
> MP3, if I was storing it in the cache -I would know when I go to the
> index it that I have an instance of something that has extra data I
> would like to index (ie its not really a pojo): at that point I can
> extract whatever data out of the "rich" object (meta data, or whatnot)
> and stick that in the Work object for HS to do its thing on (say based
> on known MIME types, as one instance).
>
> I have tried out something like this, by messing with the
> QueryInterceptor (and the tests):
>
> So I would propose some mechanism to register for the QueryInterceptor
> a surrogate class for indexing purposes (which while only take effect
> when it gets asked)  - so when it calls addToIndexes(value, key) -
> then if if a surrogate is available it will create it, and pass it to
> searchFactory.getWorker().performWork(new Work(surrogate... etc... -
> where the surrogate is created based on the value type (as well as its
> contents) - and thus searching will return what I want (as opposed to
> nothing).
>
> Q1: Does this even make sense? Should I just be pushing a "surrogate"
> type object into the cache in the first place (doesn't feel right-
> changing what I would store for the purposes of indexing)?
> Q2: Is there any way we can query heterogenous caches ie caches like
> Cache<String, SomeParent> where there are many children of SomeParent.
> (so in a query we would declare we are only interested in specific
> instances types? )
>
> Thoughts?
>
>
> -- 
> Michael D Neale
> home: www.michaelneale.net
> blog: michaelneale.blogspot.com
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev