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 pro
Noble Paul നോബിള് नोब्ळ् wrote:
>
> I suspect only one thing
> are the data types same for productid and product.id
> in the db?
>
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 dat
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 ru
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 t
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
So it is likely that you get an OOM if the DB table has a lot of rows.
processor="CachedSQLEntityProcessor" is wrong
proces
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
On Tue, Nov 25, 2008 at 11:35 PM, Amit Nithian <[EMAIL PROTECTED]> wrote:
> Thanks for the responses. Few follow-ups:
> 1) It seems that the CachedSQLEntityProcessor performs the where clause in
> memory on the cache. Is this cache an in memory RDBMS or maps?
It is a hashmap in memory
> 2) In the e
Thanks for the responses. Few follow-ups:
1) It seems that the CachedSQLEntityProcessor performs the where clause in
memory on the cache. Is this cache an in memory RDBMS or maps?
2) In the example, there were two use cases, one that is like query="select
* from Y where xid=${X.ID}" and another whe
every row emitted by an outer entity results in a new Sql query in the
inner entity. (yes 50 queries on inner entity)So,if you wish to
join multiple tables then nested entities is the way to go.
CachedSqlEntityProcessor is meant to help you reduce the number of
queries fired on sub-entities.
On Tue, Nov 25, 2008 at 1:52 PM, Amit Nithian <[EMAIL PROTECTED]> wrote:
>
> I like the concept of having multiple entity blocks for clarity but why
> wouldn't I have (for DB efficiency), the following as one entity's SQL
> statement "select * from X,Y where x.id=y.xid" and have two fields
> point
I am starting to look at Solr's Data Import Handler framework and am quite
impressed with it so far. My question is in trying to reduce the number of
SQL queries issued to the database and saw this entity processor.
In the following example:
I like the concept of having multiple entit
11 matches
Mail list logo
