Re: [infinispan-dev] Flexible indexing - an idea
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev