I am raising an issue for better error checking in CachedSqlEntityprocessor https://issues.apache.org/jira/browse/SOLR-884
On Wed, Nov 26, 2008 at 9:34 PM, Steffen B. <[EMAIL PROTECTED]> wrote: > > > Noble Paul നോബിള് नोब्ळ् wrote: >> >> I suspect only one thing >> are the data types same for productid and product.id >> in the db? That should not be the case . The names do not matter only the values do. I am running out of clues If you are good at java it might do some help to hook it up on a debugger. I guess you are using a trunk build. The place where you may find something useful information is EntityProcessorBase#getIdCacheData() >> > > Good point. I just checked and they are both int(11). Could the problem be > caused by the different column names, id in the products table and productid > in the data-table? > > > >>> 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 >> > > Then why not support both? "where" and "cachekey"? =) > Thanks for your help! > Steffen > -- > View this message in context: > http://www.nabble.com/CachedSqlEntityProcessor%27s-purpose-tp20676874p20703855.html > Sent from the Solr - User mailing list archive at Nabble.com. > > -- --Noble Paul
