I've been discussing this topic with Amit and also have some questions...
Noble Paul നോബിള് नोब्ळ् wrote:
>
> On Tue, Nov 25, 2008 at 11:35 PM, Amit Nithian <[EMAIL PROTECTED]> wrote:
>> 2) In the example, there were two use cases, one that is like
>> query="select
>> * from Y where xid=${X.ID}" and another where it's query="select * from
>> Y"
>> where="xid=${x.ID}. Is there any difference in how
>> CachedSQLEntityPRocessor
>> behaves? Does it know to strip off the WHERE clause and simply cache the
>> "select * from Y"?
> It fetches all the rows using the 'query' first.
>
> he where="xid=x.id" (see no ${} here )
> is evaluated in the map. In the map all the xid values will be kept as
> keys and the lookup is done on the map after evaluating the value of
> 'x.id' as ${x.ID}
>
If I'm not mistaken, this behaviour would require that the query I use
returns the column I want to match on, too. Without the
CachedSQLEntityProcessor, my entity for fetching multi-valued manufacturers
could look like this: ("product" is the parent entity)
<entity query="SELECT manufacturer FROM product_data WHERE id=${product.id}
AND type='manu'" />
Now if I wanted to use the cache, what would the query look like...? I tried
this:
<entity query="SELECT manufacturer,id FROM product_data WHERE type='manu'"
where="id=product.id" processor="CachedSQLEntityProcessor" />
That seems to be a pretty counter-intuitive change, which isn't explained at
all in the Wiki. =| Also, it didn't work for me, the query that is executed
returns zero rows, when I debug it with the dataimport.jsp-tool. The cache
seems to get filled though, as I encountered some JVM out-of-memory errors
when trying to cache huge tables... ;)
--
View this message in context:
http://www.nabble.com/CachedSqlEntityProcessor%27s-purpose-tp20676874p20698724.html
Sent from the Solr - User mailing list archive at Nabble.com.
