As Solr's Streaming Expression support grows more statistical and data analysis
functionality, I thought it would be useful to have first-class support in R.
To this end, I've begun an R package for this here:
https://github.com/jdyer1/R-solr-stream
At this point, this new package allows users
I committed the updated hsqldb jar today, along with its sha1. Pre-commit
passes for me. Does anyone know why Jenkins is complaining and if there is
anything I must do to fix this?
James Dyer
Ingram Content Group
-Original Message-
From: Policeman Jenkins Server [mailto:jenk...@thetap
ere is work underway for spinning up worker nodes that
are not attached to a SolrCore.
Joel Bernstein
http://joelsolr.blogspot.com/
On Tue, Apr 25, 2017 at 3:25 PM, Dyer, James
mailto:james.d...@ingramcontent.com>> wrote:
Using JDBCStream, Solr cannot find my database driver if I put t
Using JDBCStream, Solr cannot find my database driver if I put the .jar in the
shared lib directory ($SOLR_HOME/lib). In order for the classloader to find
it, the driver has to be in the server's lib directory. Looking at why, I see
that to get the full classpath, including what is in the shar
I would think it unfortunate if this ever happens. Solr in non-cloud mode is
simple, easy-to-understand, has few moving parts. Many installations do not
need to shard, have real-time-updates, etc. Using the replication handler in
"legacy mode" works great for us. The config files are on the
I know Infra has tried a number of things to resolve this, to no avail. But
did we try "git-svn --revision=" to only mirror "post-LUCENE-3930" (ivy,
r1307099)? Or if that's not lean enough for the git-svn mirror to work, then
cut off when 4.x was branched or whenever. The hope would be to giv
I'm looking at this failure. I cannot reproduce this on Linux using:
ant test -Dtests.class="*.SpellCheckComponentTest"
-Dtests.seed=110D525A21D16B1:8944EAFF0CE17B49
Tomorrow I will try this on Windows.
James Dyer
Ingram Content Group
-Original Message-
From: Policeman Jenkins Server
Safat,
DirectSolrSpellChecker defaults to Levenshtein Distance to determine how
closely related the query terms are versus the actual terms in the index. (see
https://en.wikipedia.org/wiki/Levenshtein_distance) . This is not an
English-specific metric and it works for many languages.
Assumin
+1 to stay on 1.7, from another small scale committer.
I do not see any compelling reason to upgrade to 1.8, except as Benson says for
"minor programming conveniences".
My company would be one of the ones you'd be shutting out if we were on 1.8
now. (Some of our apps upgraded to 1.7 this year.
Alexandre,
I think that writing a new entity processor for DIH is a much less risky thing
to commit than, say, SOLR-4799. Entity Processors work as plug-ins and they
aren't likely to break anything else. So a Morphline EntityProcessor is much
more likely to be evaluated and committed.
But li
Alessandro,
The "spellcheck.collate" feature already supports this by specifying
"spellcheck.maxCollationTries" greater than zero. This is useful both to
prevent unauthorized access to data and also to guarantee that suggested
collations will return some results.
But "maxCollationTries" accom
Chris,
I'm basing my opinion here on this statement,
"The method ResultSet.getString, which allocates and returns a new String
object, is recommended for retrieving data from CHAR, VARCHAR, and LONGVARCHAR
fields."
from section 9.3.1 of this document:
http://docs.oracle.com/javase/1.4.2/docs/
Yes, that is correct. So it is going to do "resultSet.getString(zzz)" for any
type it cannot address with the case statement. This should be fine if your db
is returning a LONGVARCHAR. I see in the code also if you specify it will do resultSet.getObject(zzz) on everything.
I doubt it, but t
I think this code snippet attempts to map the schema.xml types to database
types.
If your database is indeed sending this as a LONGVARCHAR, I would expect a
default "resultset.getString(index)" to correctly get text from a LONGVARCHAR
column.
James Dyer
Ingram Content Group
(615) 213-4311
My apologies. I will revert now.
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: Michael McCandless [mailto:luc...@mikemccandless.com]
Sent: Monday, May 20, 2013 2:48 PM
To: Lucene/Solr dev
Subject: Re: svn commit: r1484015 - in
/lucene/dev/branches/lucene_solr
I think you're confusing the hierarchy of your database's types with the
hierarchy in Java. In Java, a java.sql.Blob and a java.sql.Clob are 2
different things. They do not extend a common ancestor (excpt
java.lang.Object). To write code that deals with both means you need to have
separate p
I think what it comes down to is that a Clob "is-not-a" Blob. So any code
dealing with Clobs that also wants to deal with Blobs and do the same thing
with them is going to need to first check the object type returned from the
jdbc driver then do separate logic depending on the object type retur
I think the usual practice is to use BLOB types to store data that is not a
character stream. So you case is probably pretty rare. If casting solves the
issue, then why not? I think people use casts all the time to solve these
types of compatibility issues. Then again if CLOBTransformer was
We use rollback (in conjunction with DIH) when doing full re-imports on a
traditional "non-cloud" index. As DIH first deletes all documents then adds
them all, its handy for it to roll back its changes if something goes wrong.
Then the indexing node can simply return to service executing queri
Sameday it would be nice to see DIH be able to run in its own JVM for just the
reason Jack mentions. There are quite a few neat things like this that could
be done with DIH, but I've tried to work more on improving the tests, fixing
bugs, and generally making the code more attractive to develop
3, at 11:47 AM, "Dyer, James"
wrote:
> Do you think it is appropriate that we put all of this in a section in the
> release notes, or something more succinct?
>
> James Dyer
> E-Commerce Systems
> Ingram Content Group
> (615) 213-4311
>
>
> -Origina
AM
To: dev@lucene.apache.org
Subject: Re: 4.1 release notes: please review
Hi James,
Please go ahead edit the wiki page - I'm sure you'll do a better job of
summarizing these than me.
Steve
On Jan 17, 2013, at 11:31 AM, "Dyer, James"
wrote:
> Steve, This is pretty lo
Steve, This is pretty longwinded and maybe just the first sentence will suffice
with "see the wiki for more information." All of this is documented there,
more or less. None of this will affect very many people.
--
The DataImportHandler contrib module has some minor backwards-compatibi
Jack,
Did you test this to see if you could trigger this bug? But in any case, can
you open a jira ticket so this won't fall under the radar? Even if the comment
that was put here is true I guess we should minimally throw an exception, or
use the first one and log a warning, maybe?
James Dye
ded configuration by request, right?
On Friday, January 11, 2013 at 11:06 PM, Dyer, James wrote:
> I don't mean to discourage you but I was kinda hoping if SOLR-4151 was left
> for dead long enough and people got used to it not being there we could just
> kill DebugLogger...
I&#
The behavior was changed in 4.0-ALPHA with SOLR-2115. See especially my
comment from July 20, 2012. There are 3 important changes here:
- you can specify a new data-config.xml filename or location on the request
using the "config" parameter. You do not need to put one in solrconfig.xml,
but s
I can faithfully reproduce a failure in Trunk on this test with:
-Dtests.seed=3FACDC7EBD23CB80:3D65D783617F94F1
this happens both in Linux and Windows.
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
---Original Message-
From: Robert Muir [mailto:rcm...@gmail.com]
Sent: Monday, December 10, 2012 9:57 AM
To: dev@lucene.apache.org
Subject: Re: lost entries in trunk/lecene/CHANGES.txt
On Mon, Dec 10, 2012 at 10:53 AM, Dyer, James
wrote:
> Perhaps the issue is when I do a merge, if I noti
I do apologize for causing problems. But I do usually merge. However, if it
is a trivial change (say, just a small test fix) it is a ton faster to just
make the change to both branches instead of a merge. I guess I do not
understand why this causes problems with seemingly unrelated code (I ca
ahhh. I did not know that Policeman overrides (or that you could override) the
run-test-serially setting in DIH's build.xml. This explains everything as
placing the file in a private temp directory rather than the default "conf" dir
would solve the issue.
I think then if I keep it as it is (
Whenever I want to know who "owns" a piece of code, I just look at the svn
history to see who has been modifying it.
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
-Original Message-
From: David Smiley (@MITRE.org) [mailto:dsmi...@mitre.org]
Sent: Thursday, Novembe
By any chance is this Jenkins using Java 8 before JDK 8-ea-b65 ? If so, then
it might be hitting https://issues.apache.org/jira/browse/DERBY-5958, which, at
least according to the comments, only occurs on earlier revisions of JDK 8.
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-
y that makes it so you can visit it with your firewall - it may still
be detected as a dynamic ip service though. We will see I guess.
- Mark
On Nov 20, 2012, at 4:36 PM, "Dyer, James" wrote:
> Thanks Mark. I committed a fix for this.
>
> James Dyer
> E-Commerce Systems
>
rol.java:358)
at java.lang.Thread.run(Thread.java:722)
On Tue, Nov 20, 2012 at 3:58 PM, Dyer, James
wrote:
> Mark,
>
> Can you tell me which test failed? I still cannot get into Fullmetal
> Jenkins. Unfortunately my company's firewall blocks it due to "Dynamic DNS&
Mark,
Can you tell me which test failed? I still cannot get into Fullmetal Jenkins.
Unfortunately my company's firewall blocks it due to "Dynamic DNS".
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
-Original Message-
From: Mark Miller [mailto:markrmil...@gmail.com
I noticed this and made a subsequent fix for this test (4x: r1411348 / trunk:
r1411334). I'm having difficulty getting to this Jenkins so I'm not sure if
this failure is before or after this commit?
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
From: Robert Muir [mailto:rcm
Thank you!
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
-Original Message-
From: Steve Rowe [mailto:sar...@gmail.com]
Sent: Tuesday, November 13, 2012 6:07 AM
To: dev@lucene.apache.org
Subject: Re: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #153: POMs out of sync
I comm
My mistake, sorry. I've got these tests set to @Ignore for now, with a better
fix to follow soon.
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
-Original Message-
From: Policeman Jenkins Server [mailto:jenk...@sd-datasolutions.de]
Sent: Monday, November 05, 2012 12:
code should be changed?
On Tue, Oct 30, 2012 at 4:15 PM, Dyer, James
mailto:james.d...@ingramcontent.com>> wrote:
This was done with https://issues.apache.org/jira/browse/SOLR-2124 . The idea
is that it is enough to get a 1-line log whenever PingRequestHandler is hit
(which will have the re
03, and this is
something I would like to see logged.
Maybe that exception code should be changed?
On Tue, Oct 30, 2012 at 4:15 PM, Dyer, James
mailto:james.d...@ingramcontent.com>> wrote:
This was done with https://issues.apache.org/jira/browse/SOLR-2124 . The idea
is that it is enough to get
This was done with https://issues.apache.org/jira/browse/SOLR-2124 . The idea
is that it is enough to get a 1-line log whenever PingRequestHandler is hit
(which will have the response code). There is no need to also log a severe
exception with a stack trace as this is not really an error condi
Is there any way we can limit the size of the messages Jenkins emails this
list? Responsing to a "your mailbox is full" warning, I found I had 32 recent
Jenkins messages all over 1mb (a few were >10mb). A few weeks ago I returned
from vacation to find my mail account partially disabled because
>From my perspective, working for a company that uses Solr on a bunch of apps,
>I really wish we keep it agnostic. I see the case for documenting that "our
>testing process exclusively uses Jetty 7, we've included it in our
>distribution, and we recommend it". But I don't see why we need to be
Bill,
As you know, it really depends on the size of your index combined with which
features you're using. There is really no substitute for having a good load
test and monitoring tool and to run multiple tests while trying different
settings.
My guess is that you're experiencing "full" gc's,
I did a little digging on this and I'm not sure relying on JavaDB is such a
sure bet. Its a verbatim copy of Derby 10.2 and while bundled in with the jvm,
its not in the classpath by default. Also, I have 2 Oracle 1.6 JVMs on my PC
and only 1 includes it. Also, while the documentation says it
Let me apologize in advance for my (almost) complete ignorance of everything
build related: Maven, Ivy, Ant, etc. Sorry!
For Solr-3430, I am introducing a dependency to derby.jar, which will be needed
only to run DIH tests. So I don't want it included in the Solr .war. It just
needs to be i
This is a test bug. I am committing a fix...
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
-Original Message-
From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
Sent: Monday, April 23, 2012 2:09 PM
To: dev@lucene.apache.org
Subject: [JENKINS] Lucene-Solr
I would like to commit SOLR-3361 to 3.6 in case there is a 3.6.1. Should I
start a new 3.6.1 section in changes.txt? Does it just go under 4.0 or 3.0
with a note that it is in the 3.6 branch also (but not released)?
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
Looked a little more into it and found the issue is that
"http://cloud.github.com/downloads/rmuir"; is blocked on the network I'm on. Is
hosting these on Robert's github space a permanent arrangement? If so, I
imagine I can get the jars from an old checkout and manually put them in the
ivy r
SOLR-3011 (3.x only bug fixes for DIH Threading) included some more-intense
multi-threaded unit tests. I fear that the bugs were not fully solved but
occur on certain platforms/environments. This is the second time this test has
failed this week, both times during the Maven build. I'd imagine
Whenever I try to run tests for 3.x I am getting problems with the jetty jars
for the solr example. Before the checksums were added I was getting an error
reading the jar. Now I get a bad checksum error.
[licenses] CHECKSUM FAILED for ...
solr\example\lib\jetty-6.1.26-patched-JETTY-1340.jar (
I tried this seed on my 4-core Windows machine several times but no failure.
This test failure might indicate that the DIH threading bugs aren't really
fixed in 3.6. On the other hand, users of DIH "threads" on 3.6 will get a
deprecation warning, the wiki discourages it and the feature is gone
-Original Message-----
From: Dyer, James [mailto:james.d...@ingrambook.com]
Sent: Wednesday, March 21, 2012 3:40 PM
To: dev@lucene.apache.org
Subject: RE: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #432: POMs out of sync
I'm looking at it.
James Dyer
E-Commerce Systems
Ingram Content
I'm looking at it.
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
-Original Message-
From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
Sent: Wednesday, March 21, 2012 3:35 PM
To: dev@lucene.apache.org
Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #432:
got it. Also I updated a few links in the wiki, and put an obsolete notice
(with a link) on the page about editing Forrest.
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
-Original Message-
From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
(wana update the i
I got my name on the staging site, but the instructions still have "TBD" for
publishing to the real site. Help?
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
A couple years ago I was told we were going to be adding tons of new docs to
Search and we needed to do so low-cost. Only problem, our search vendor
licensed their product by the document, making the low-cost goal impossible.
I had seen Solr mentioned in the footnote of a book somewhere and tho
I'm wondering if the import for "org.eclipse.jdt.core.dom.ThisExpression" in
SolrCore.java introduced in r1196797 (SOLR-2861) was a mistake. It adds an
additional .jar dependency and doesn't seem to be used.
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
Michael,
A while ago I submitted SOLR-2462 with a patch to fix a critical bug in Solr's
spellchecker. I'm not sure if the patch included is the best approach to
fixing the problem but I do think any next release should include a fix for
this.
James Dyer
E-Commerce Systems
Ingram Content Group
We have a situation where we have data coming from several long-running queries
hitting multiple relational databases. Other data comes in fixed-width text
file feeds, etc. All of this has to be joined and denormalized and made into
nice SOLR documents. I've been wanting to use DIH as it seem
We were working with 2 versions of the functionality and decided that the one
that doesn't require modifications to SearchHandler and ResponseBuilder would
perform better in most sitations. So you won't see any changes to these 2
classes. The functionality should work.
James Dyer
E-Commerce S
) Improvements to
SpellCheckComponent Collate functionality
Hi James,
Did you see my comments on the issue?
On Aug 11, 2010, at 12:28 AM, Dyer, James wrote:
> Tom,
>
> I'm going to also need this to work with 1.4.1 within the next month
or two so if someone else doesn't back-port
Tom,
I'm going to also need this to work with 1.4.1 within the next month or two so
if someone else doesn't back-port it to 1.4.1 then I probably will. I also
would like to see this working with shards. The PossibilityIterator class
likely can be made a lot simpler. If nobody else takes care
63 matches
Mail list logo
