[infinispan-dev] Flexible indexing - an idea

[Emmanuel Bernard]

But at the end of the day you need to know which property is indexed  
and how. and for a byte[], you need to know / discover its type to  
extract the textual representation.
It's not magic, if we don't have the text, we can't index.

On 29 sept. 09, at 10:28, Michael Neale wrote:

> yes well I was thinking that.
>
> But in the case of web caching, for instance, you tend to have a
> byte[] and then a mime type - and that is about it.
> If it was uniform content, sure, could have pojos for everything.
>
> Another case, JSON - don't necessarily want to put that into pojos
> (and in any case, a map of maps would be the closest thing - which
> isn't really a pojo in that sense anyway). Say if one was building a
> distributed database *cough* *cough* ;)
>
> Yes this would be totally transparent - its only for certain things
> (maybe let the user hook into it, but they shouldn't need to worry).
>
>
>
>
> On Tue, Sep 29, 2009 at 6:08 PM, Emmanuel Bernard
> <emmanuel at hibernate.org> wrote:
>> 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
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
>
> -- 
> 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