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
wrote:
> Thanks both for the advice.
>
> Erick, which message were you referring to when you said "But
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::te
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> ma
I'm currently re-indexing with the cast to string in the sql statement. It
looks good so far.
On Thu, 14 Nov 2019 at 14:13, Jörn Franke wrote:
> You can use an updateScript handler to do this kind of postprocessing or
> you can cast it in your sql Statement as string.
>
>
> > Am 14.11.2019 um 14
You can use an updateScript handler to do this kind of postprocessing or you
can cast it in your sql Statement as string.
> Am 14.11.2019 um 14:09 schrieb Boris Chazalet :
>
>
> I dug a little in the dataimport code, and there's a special case for
> BigDecimal in the JdbcDataSource class, he
If that's right, I'd be happy to try to provide a bug fix, although do not
know the first about contributing to the solr project.
On Thu, 14 Nov 2019 at 14:09, Boris Chazalet
wrote:
> I dug a little in the dataimport code, and there's a special case for
> BigDecimal in the JdbcDataSource class,
I dug a little in the dataimport code, and there's a special case for
BigDecimal in the JdbcDataSource class, here exactly:
https://github.com/apache/lucene-solr/blob/faaee86efb01fa6e431fcb129cfb956c7d62d514/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.j
Thanks for your response Jörn. Yes, I saw the prefix and I suspect this is
the problem. But I'm not doing anything special in the DIH config, this is
a minimalized version of it:
The field is a UUID in the database, so it's definitely v
It seems there is a prefix java.util.UUID: in front of your UUID. Any idea
where it comes from? Is it also like this in the database? Is your import
handler maybe receiving a java object java.util.UUID and it is not converted
correctly to string?
> Am 14.11.2019 um 11:52 schrieb Boris Chazalet
Also, if I manually add the document from collection's document tab in the
UI (using /update handler with CSV Document Type), I just works.
On Thu, 14 Nov 2019 at 12:08, Boris Chazalet
wrote:
> Few things I forgot to mention:
> - I'm running on java 8
> - the collection where the problem happen
Few things I forgot to mention:
- I'm running on java 8
- the collection where the problem happens is made of 3 shards with 3 NRT
replicas each.
On Thu, 14 Nov 2019 at 11:52, Boris Chazalet
wrote:
>
> Hi,
>
> I'm running into an issue with Solr 8.3.0: it fails at indexing a schema
> with UUID f
Hi,
I'm running into an issue with Solr 8.3.0: it fails at indexing a schema
with UUID field.
I'm using a SolrCloud setup with 3 instances, and I'm using the DIH to
fetch and index the data from a postgres database.
In schema.xml I have:
The data-config is a simple select, the uuid f
12 matches
Mail list logo
