You do not have to take up complete trunk. Solr can continue to be 1.3
and DIH can be a nightly . DIH is shipped as a separate jar in the
same .war file
This can minimize your risks
On Tue, Dec 30, 2008 at 4:54 PM, Shalin Shekhar Mangar
<shalinman...@gmail.com> wrote:
> On Tue, Dec 30, 2008 at 3:33 PM, Manupriya <manupriya.si...@gmail.com>wrote:
>
>>
>> Thanks Shalin and Noble for all the help.
>>
>> I looked into the source code of 1.3 for the Null Pointer that I was
>> getting. And indeed, there was a problem. In release 1.3,
>> SqlEntityProcessor
>> doesnt handle 'deltaImportQuery' for delta imports. But this problem is
>> fixed in the nightly build.
>
>
> DataImportHandler in the Solr 1.3 release supports delta imports. In that
> version we used to generate the query ourselves after detecting the changed
> primary key. This was not very flexible and worked only for very simple
> queries. Due to this the deltaImportQuery attribute was introduced (after
> release 1.3). You can use deltaImportQuery to exactly specify what query
> should be executed once the primary key of a changed row is identified. The
> example given in the wiki should work with Solr 1.3 release.
>
> So now I have one question, we were planning to use Delta Import feature of
>> Solr in our production environment. And the latest stable release (1.3)
>> doesnt support all the features for Delta Import. So is it advisable to use
>> one of the nightly builds in production environement? I am new to Solr, so
>> I
>> need expert opinion in decision making.
>
>
> If the problem was related only to case sensitive names and your import
> works without deltaImportQuery then you should use 1.3 otherwise you don't
> have a lot of choice :)
>
> All the normal caveats of trunk code apply to 1.4, however I believe it is
> fairly stable.
>
>
>>
>> --------------------------------------------------------------------------------------------------
>> Apart from this, I realized, Solr is 'case sensitive', while resolving
>> variable values.
>>
>> For example, the following entity definition gives SQl syntax exception
>> because the varaible is 'id' in deltaQuery and 'ID' in deltaImportQuery.
>>
>> <entity name="item" pk="ID" query="select * from item"
>> deltaQuery="select id from item where last_modified >
>> '${dataimporter.last_index_time}'"
>> deltaImportQuery="select * from item where
>> ID=${dataimporter.delta.ID}">
>>
>> ------------------------------------------------------------------------------------------------
>> And the following definition works fine.
>>
>> <entity name="item" pk="ID" query="select * from item"
>> deltaQuery="select ID from item where last_modified >
>> '${dataimporter.last_index_time}'"
>> deltaImportQuery="select * from item where
>> ID=${dataimporter.delta.ID}">
>>
>> It took me sometime to figure this out and also some looking into the code.
>> I wrongly assumed it to behave like normal SQL query.
>>
>> Is this case-sensitivity intentional? Is it documented somewhere that I can
>> refer for constructing queries for Delta/Full Import?
>
>
> There was a bug related to case-sensitivity in 1.3 which has been fixed in
> trunk. Now, unless you specify the 'name' attribute for a field DIH does
> case-insensitive matches. If you are providing a 'name' it must be in the
> same case as the column name returned by SQL.
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
--
--Noble Paul
