Last thing to note, that doesn't happen on the standalone 8.3.0 version of
solr, as this is where I did my preliminary testing without any problem.
On Thu, 14 Nov 2019 at 15:25, Boris Chazalet <bchaza...@companywatch.net>
wrote:
> Thanks both for the advice.
>
> Erick, which message were you referring to when you said "But now your
> uuid fields will look like this, right?"?
>
> I finished indexing my 45 millions documents successfully by casting the
> UUID in the SQL itself like this (that's for a postgres db):
> SELECT myuuidfield::text, mypk FROM {{solr__datasource}}
>
> I'm happy with the workaround as I can keep my UUID type in the solr
> schema and in my database, but it still feels that something in the data
> import logic isn't handling the UUID type coming from the JDBC driver
> correctly.
>
> On Thu, 14 Nov 2019 at 14:43, Erick Erickson <erickerick...@gmail.com>
> wrote:
>
>> But now your uuid fields will look like this, right?
>>
>> java.util.UUID:4ee3992e-0b2d-e811-89a7-0025900429ba
>>
>> This looks like somewhere in DIH it’s doing a cast from an object….
>>
>> Which will be a real head-scratcher for anyone looking at these. There
>> are three other alternatives I can think of:
>>
>> 1> make your SQL statement output this as some kind of string.
>> 2> The aforementioned ScriptUpdateProcessor can transform this into
>> "4ee3992e-0b2d-e811-89a7-0025900429ba” with your favorite scripting language
>> 3> use a PatternReplaceCharFilter to transform this before it gets to the
>> indexing process. I’m not totally sure this’ll work, I’m not sure where
>> this check is done, but it’d be the easiest if it does.
>>
>> Best,
>> Erick
>>
>>
>>
>> > On Nov 14, 2019, at 8:17 AM, Boris Chazalet <bchaza...@companywatch.net>
>> wrote:
>> >
>> > java.util.UUID:4ee3992e-0b2d-e811-89a7-0025900429ba
>>
>>
>
> --
>
>
> *Boris Chazalet*Senior developer and problem solver
> [image: Co_watch_signature]
> T: +44 (0)20 3740 9402
> E: bchaza...@companywatch.net
>
>
>
>
>
--
*Boris Chazalet*Senior developer and problem solver
[image: Co_watch_signature]
T: +44 (0)20 3740 9402
E: bchaza...@companywatch.net
--
This message is
intended only for the addressee and unless otherwise stated
is commercial in confidence and may contain information that is privileged.
Where all recipients are in the companywatch.net <http://companywatch.net>
domain, this communication is classified as Confidential. Unauthorised use
is strictly prohibited and may be
unlawful. If you are not the addressee,
you should not read, copy,
disclose or otherwise use this message, except
for the purpose of delivery to
the addressee. If you have received this in
error, please delete and
advise us immediately. Although Company Watch
makes every reasonable
effort to keep its network and systems free from
viruses, the company accepts
no responsibility for computer viruses
transmitted through this mail or in any
attachments. It is your
responsibility to virus scan any attachments we
send to you.
Company
Watch Limited is a company registered in England & Wales with
company
number 3597613
Centurion House, 37 Jewry Street, London, EC3N 2ER
Please consider the environment before printing this email
