Re: Solr DataConfig / DIH Question
Guys??? You are in the wrong thread. Please, send a message to the mailing list, do not answer to existing posts. Thank you. -- View this message in context: http://lucene.472066.n3.nabble.com/Solr-and-Nutch-Droids-to-use-or-not-to-use-tp890640p892041.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: how to patch?
check this http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201003.mbox/%3c495b6571003260900p2d1e7a01ib5aa211f84379...@mail.gmail.com%3e 2010/6/13 Li Li > I want to use fast highlighter in solr1.4 and find a issue in > https://issues.apache.org/jira/browse/SOLR-1268 > File Name Date Attached ↑ > Attached By Size > SOLR-1268.patch 2010-02-05 10:32 PM > Koji Sekiguchi4 kB > SOLR-1268-0_fragsize.patch 2010-02-04 10:43 PM > Koji Sekiguchi2 kB > SOLR-1268-0_fragsize.patch 2010-01-29 11:51 PM > Koji Sekiguchi1 kB > SOLR-1268.patch 2010-01-03 11:27 PM > Koji Sekiguchi 48 kB > SOLR-1268.patch 2010-01-02 10:42 PM > Koji Sekiguchi 35 kB > > I am not familiar with patch. There are 3 patch named SOLR-1268, which > one shoud I use? I guess I should the newest one but it's so small. > SOLR-1268-0_fragsize also have 2 files > -- Abdelhamid ABID Software Engineer- J2EE / WEB
dealing with dash chars in fields when using dismax
Hi, I am using dismax on solr 1.4 and I am running into an issue with fields that contain dash chars: Foo-Bar - Company Now if someone searches for exactly "Foo-Bar - Company" the resulting dismax query would disallow "Company" when trying to find a match. Obviously I could just ignore all "-" in any query strings, but that would prevent power users from prohibiting words is there some magic I can enable that would make this use case possible with sensible scoring for the results? Of course I could put in some work on the client side to index things accordingly, but I guess in that case I rather just remove support for prohibiting words. regards, Lukas Kahwe Smith m...@pooteeweet.org
problem whith solr slave replication
Hi all, i've setup solr replication as described here : http://wiki.apache.org/solr/SolrReplication#enable.2BAC8-disable_master.2BAC8-slave_in_a_node On my slave server data/ is plain of index.$timestamps that aren't commited in the main index/ is this a bug? how can i force the commit of a replicated index after the download? thank you in advance -- ciao giskard
error running dih import
Hi, what could cause this issue? i cannot reproduce it on my dev machine, but i am pretty sure its not an access control issue in either the file system nor the database. INFO: Creating a connection for entity entitydelete with URL: jdbc:mysql://localhost/foo Jun 13, 2010 4:06:54 PM org.apache.solr.handler.dataimport.JdbcDataSource$1 call rImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.Util.getInstance(Util.java:381) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1030) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3558) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3490) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2109) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2642) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2571) at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:782) at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:625) at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.(JdbcDataSource.java:246) ... 12 more Jun 13, 2010 4:13:47 PM org.apache.solr.update.DirectUpdateHandler2 rollback INFO: start rollback Jun 13, 2010 4:13:47 PM org.apache.solr.update.DirectUpdateHandler2 rollback INFO: end_rollback regards, Lukas Kahwe Smith m...@pooteeweet.org
Re: dealing with dash chars in fields when using dismax
Have you tried escaping the dashes? Your dismax definition and the output from the analysis admin page would also help. Best Erick On Sun, Jun 13, 2010 at 5:27 AM, Lukas Kahwe Smith wrote: > Hi, > > I am using dismax on solr 1.4 and I am running into an issue with fields > that contain dash chars: > Foo-Bar - Company > > Now if someone searches for exactly "Foo-Bar - Company" the resulting > dismax query would disallow "Company" when trying to find a match. > Obviously I could just ignore all "-" in any query strings, but that would > prevent power users from prohibiting words is there some magic I can enable > that would make this use case possible with sensible scoring for the > results? > > Of course I could put in some work on the client side to index things > accordingly, but I guess in that case I rather just remove support for > prohibiting words. > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > > >
Re: dealing with dash chars in fields when using dismax
On 13.06.2010, at 16:57, Erick Erickson wrote: > Have you tried escaping the dashes? Your dismax definition > and the output from the analysis admin page would also help. sure .. escaping ends up being the same as removing. but i guess it would be the better approach of course. but still is there some clean solution that doesnt mean a lot of coding work on my end to handle dash both as a special and as a normal char. something like doing the search twice both with the dash escaped and not escaped and then some intelligent scoring to produce the final result set. regards, Lukas Kahwe Smith m...@pooteeweet.org
Re: dealing with dash chars in fields when using dismax
<<>> I don't think so. Removing would mean that the same exact match search would match documents with and without hyphens. I.e. searching for "my - way" would match either original content of "my way" or "my - way". Whereas escaping the hyphen would cause only the correct exact match to be returned. This may or may not be desired behavior... <<>> And how would the code know? You're essentially asking for DWIM (Do What I Mean) functionality, which I've been awaiting for many years It seems a reasonable approach would be to have your power users understand they needed to escape hyphens. Or introduce your own syntax for negation which would be a simple string substitution on the way through. Or. Because somewhere you need some external input that distinguishes between "I mean this hyphen to be a negation, but this other one to be a literal". If this seems irrelevant, then I'm missing your point pretty badly. A use case or two where this distinction is important would be helpful. Or is that use-case ? Best Erick On Sun, Jun 13, 2010 at 11:00 AM, Lukas Kahwe Smith wrote: > > On 13.06.2010, at 16:57, Erick Erickson wrote: > > > Have you tried escaping the dashes? Your dismax definition > > and the output from the analysis admin page would also help. > > > sure .. escaping ends up being the same as removing. but i guess it would > be the better approach of course. but still is there some clean solution > that doesnt mean a lot of coding work on my end to handle dash both as a > special and as a normal char. > > something like doing the search twice both with the dash escaped and not > escaped and then some intelligent scoring to produce the final result set. > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > > >
Re: dealing with dash chars in fields when using dismax
On 13.06.2010, at 17:20, Erick Erickson wrote: > << work on my end to handle dash both as a special and as a normal char.>>> > > And how would the code know? You're essentially asking for DWIM (Do What I > Mean) functionality, which I've been awaiting for many years > > It seems a reasonable approach would be to have your power users understand > they needed to escape hyphens. Or introduce your own syntax for negation > which would be a simple string substitution on the way through. Or. > Because somewhere you need some external input that distinguishes between "I > mean this hyphen to be a negation, but this other one to be a literal". > > If this seems irrelevant, then I'm missing your point pretty badly. A use > case or two where this distinction is important would be helpful. Or is that > use-case ? No, I was just wondering if someone by chance implemented the DWIM I want :) But I guess for now I will just escape, since we do not advertise + and - syntax anyway atm. Then again more and more people are learning how it works in google and are starting to just try it out when they are doing searches. What I might end up doing though is not escape dashes only in specific cases: foo-bar (escape) foo - bar (escape) foo -bar (not escape, aka probihit bar) This should enable power users and should rarely hit non power users. regards, Lukas Kahwe Smith m...@pooteeweet.org
Re: error running dih import
On 13.06.2010, at 16:46, Lukas Kahwe Smith wrote: > Hi, > > what could cause this issue? > i cannot reproduce it on my dev machine, but i am pretty sure its not an > access control issue in either the file system nor the database. > > INFO: Creating a connection for entity entitydelete with URL: > jdbc:mysql://localhost/foo > Jun 13, 2010 4:06:54 PM org.apache.solr.handler.dataimport.JdbcDataSource$1 > call > rImpl.java:39) >at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) >at com.mysql.jdbc.Util.getInstance(Util.java:381) >at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1030) >at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) >at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3558) >at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3490) >at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959) >at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2109) >at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2642) >at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2571) >at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:782) >at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:625) >at > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.(JdbcDataSource.java:246) >... 12 more > Jun 13, 2010 4:13:47 PM org.apache.solr.update.DirectUpdateHandler2 rollback > INFO: start rollback > Jun 13, 2010 4:13:47 PM org.apache.solr.update.DirectUpdateHandler2 rollback > INFO: end_rollback it seems the issue was caused by NULL values that i was referencing inside a nested query. generally the error messages generated by DIH could be a lot better. in the end i managed to fix the issue by reducing my DIH script to one entity tag and then going through each of them one after each other. oddly then i finally got a different error message, which included the query inside the nested entity. fixed that issue and now the import worked through. weird. regards, Lukas Kahwe Smith m...@pooteeweet.org
Re: dealing with dash chars in fields when using dismax
There will always be edge cases and the parser cannot be all things to all people. Most applications have an application layer that create the actual Solr query, and that is where you'll have to handle this one. On Sun, Jun 13, 2010 at 8:25 AM, Lukas Kahwe Smith wrote: > > On 13.06.2010, at 17:20, Erick Erickson wrote: > >> <<> work on my end to handle dash both as a special and as a normal char.>>> >> >> And how would the code know? You're essentially asking for DWIM (Do What I >> Mean) functionality, which I've been awaiting for many years >> >> It seems a reasonable approach would be to have your power users understand >> they needed to escape hyphens. Or introduce your own syntax for negation >> which would be a simple string substitution on the way through. Or. >> Because somewhere you need some external input that distinguishes between "I >> mean this hyphen to be a negation, but this other one to be a literal". >> >> If this seems irrelevant, then I'm missing your point pretty badly. A use >> case or two where this distinction is important would be helpful. Or is that >> use-case ? > > > No, I was just wondering if someone by chance implemented the DWIM I want :) > But I guess for now I will just escape, since we do not advertise + and - > syntax anyway atm. > Then again more and more people are learning how it works in google and are > starting to just try it out when they are doing searches. > > What I might end up doing though is not escape dashes only in specific cases: > foo-bar (escape) > foo - bar (escape) > foo -bar (not escape, aka probihit bar) > > This should enable power users and should rarely hit non power users. > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > > > -- Lance Norskog goks...@gmail.com
Re: Question about specifying the query analysis at query time
: stopword.txt has the same words in the index and query analyzer. The thing : is, in some search requests (not all of them) want to add some extra : stopwords (at query time). The 3 fields would have the same extra stopwords. : I want these extra stopwords to be indexed in the index but that some : searches never find these words. I would suggest you write a custom QParser that knows about your special stop words, strips them out of the query string, and then delgates to another parser (by name) because really it sounds like what you want is to "cleans" the query string regardless of field -- not modify the analysis for all the fields. -Hoss
Re: Dynamic dataConfig files in DIH
I have multiple db-data-config file which I have created according to my needs. I want to be able to specify which config file to use while performing DIH. -- View this message in context: http://lucene.472066.n3.nabble.com/Dynamic-dataConfig-files-in-DIH-tp875421p893553.html Sent from the Solr - User mailing list archive at Nabble.com.
