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.
--
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.
