I suspect only one thing
are the data types same for productid and product.id
in the db?
On Wed, Nov 26, 2008 at 5:38 PM, Steffen B. <[EMAIL PROTECTED]> wrote:
>
> Hi Noble Paul,
> thanks for your quick response.
>
>
> Noble Paul നോബിള് नोब्ळ् wrote:
>>
>> What i expect to happen is when you run the query
>> SELECT manufacturer,id FROM product_data WHERE type='manu'
>>
>> you must get all the rows from the DB in the table product_data
>>
>
> Unfortunately, that's not the case. Taken from a real project, verbose mode:
> (names replaced)
> # run 1 - no cache processor
> Config:
> <entity name="myEntity" dataSource="my-db" pk="productid"
> query="SELECT data FROM data2productid WHERE
> productid='${product.id}' AND isdeleted=0" />
>
> Result:
> <lst name="entity:myEntity">
> <str name="query">
> SELECT data FROM data2productid WHERE productid='6' AND isdeleted=0
> </str>
> <str name="time-taken">0:0:0.25</str>
> <str>----------- row #1-------------</str>
> <str name="data">SM224950</str>
> <str>---------------------------------------------</str>
> <str>----------- row #2-------------</str>
> <str name="data">04138D01</str>
> <str>---------------------------------------------</str>
> </lst>
>
> # run 2 - cache processor
> Config:
> <entity name="myEntity" dataSource="my-db" pk="productid"
> query="SELECT data,productid FROM data2productid WHERE
> isdeleted=0" where="productid=product.id"
> processor="CachedSqlEntityProcessor" />
>
> Result:
> <lst name="entity:myEntity">
> <str name="query">SELECT data,productid FROM data2productid WHERE
> isdeleted=0</str>
> <str name="time-taken">0:0:0.249</str>
> </lst>
>
> It seems like the processor is unable to associate the cached rows with the
> matching documents and therefore won't add any cached entity data to my
> documents. Or did I make any mistakes? :(
>
>
>
>> So it is likely that you get an OOM if the DB table has a lot of rows.
>>
>
> Yes, that at least indicates, that the rows are loaded into memory. So far
> it seems to work for me.
>
>
>
>> processor="CachedSQLEntityProcessor" is wrong
>> processor="CachedSqlEntityProcessor" is right
>>
>
> Uh, little typo. My bad.
>
>
>
>> counter intuitive? which part is counter-intuitive ? the where part?
>>
>> The cache store the entire data with id value as the key
>>
>
> Yes, I wouldn't call the cache PK-attribute "where", as there can be another
> "WHERE" inside the query, too, and because it isn't actually an SQL-WHERE
> that's executed with that attribute value, right? Maybe "cacheid" or
> "cachekey" would be clearer? And an additional check for whether the chosen
> cachekey is in the result-set could minimize problems, because right now
> omitting the primary key column inside the query doesn't yield any errors.
true. that check would be helpful
as to the configuration, any changes can break back compat
> --
> View this message in context:
> http://www.nabble.com/CachedSqlEntityProcessor%27s-purpose-tp20676874p20699494.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
>
--
--Noble Paul
