[jira] Resolved: (SOLR-1135) snapshot is created in the directory where solr was lauched
[ https://issues.apache.org/jira/browse/SOLR-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-1135. - Resolution: Fixed Committed revision 770082. Thanks Jianhan! > snapshot is created in the directory where solr was lauched > --- > > Key: SOLR-1135 > URL: https://issues.apache.org/jira/browse/SOLR-1135 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 1.4 > Environment: Mac OS 10.5 >Reporter: Jianhan >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1135.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > when a request > http://master_host:port/solr/replication?command=snapshoot > is made, a snapshot is created successfully but in a wrong directory. It is > not in the data directory (like the script did) but in the directory where > solr is launched. This creates complication to backup process because this > makes the location of snapshot essential undefined, i.e. depends on how solr > is launched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-629) Fuzzy search with DisMax request handler
[
https://issues.apache.org/jira/browse/SOLR-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704491#action_12704491
]
Guillaume Smet commented on SOLR-629:
-
bq. FYI: the patch didn't seem to apply cleanly on 1.3, but worked fine on 1.4
The old version of the patch which is still attached should work with 1.3. At
least, I use it on a pre 1.3 version.
The new one is rebased on 1.4 but is the exact same patch.
{quote}
I get this as the parsed query:
"parsedquery_toString"=>"+(((title_words:the~0.6)~0.01
(title_words:game~0.6)~0.01)~2) ()"
(I don't want it running anything on the word 'the' because its a stop word)
{quote}
AFAIK, it's the standard behaviour for fuzziness (and for wildcard queries).
The stop word isn't removed because the~0.06 != the, it might be another word.
Could any Solr guy confirm?
Note that 0.06 is really too low IMHO. I usually use 0.8 or 0.7 for fuzziness.
--
Guillaume
> Fuzzy search with DisMax request handler
>
>
> Key: SOLR-629
> URL: https://issues.apache.org/jira/browse/SOLR-629
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Guillaume Smet
>Priority: Minor
> Attachments: dismax_fuzzy_query_field.v0.1.diff,
> dismax_fuzzy_query_field.v0.1.diff
>
>
> The DisMax search handler doesn't support fuzzy queries which would be quite
> useful for our usage of Solr and from what I've seen on the list, it's
> something several people would like to have.
> Following this discussion
> http://markmail.org/message/tx6kqr7ga6ponefa#query:solr%20dismax%20fuzzy+page:1+mid:c4pciq6rlr4dwtgm+state:results
> , I added the ability to add fuzzy query field in the qf parameter. I kept
> the patch as conservative as possible.
> The syntax supported is: fieldOne^2.3 fieldTwo~0.3 fieldThree~0.2^-0.4
> fieldFour as discussed in the above thread.
> The recursive query aliasing should work even with fuzzy query fields using a
> very simple rule: the aliased fields inherit the minSimilarity of their
> parent, combined with their own one if they have one.
> Only the qf parameter support this syntax atm. I suppose we should make it
> usable in pf too. Any opinion?
> Comments are very welcome, I'll spend the time needed to put this patch in
> good shape.
> Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1135) snapshot is created in the directory where solr was lauched
[ https://issues.apache.org/jira/browse/SOLR-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-1135: --- Assignee: Shalin Shekhar Mangar > snapshot is created in the directory where solr was lauched > --- > > Key: SOLR-1135 > URL: https://issues.apache.org/jira/browse/SOLR-1135 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 1.4 > Environment: Mac OS 10.5 >Reporter: Jianhan >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1135.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > when a request > http://master_host:port/solr/replication?command=snapshoot > is made, a snapshot is created successfully but in a wrong directory. It is > not in the data directory (like the script did) but in the directory where > solr is launched. This creates complication to backup process because this > makes the location of snapshot essential undefined, i.e. depends on how solr > is launched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-748) FacetComponent helper classes are package restricted
[ https://issues.apache.org/jira/browse/SOLR-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704487#action_12704487 ] Shalin Shekhar Mangar commented on SOLR-748: Wojtek, how about we just make the following changes: # Inner classes as public static # The class attributes as public # Add an experimental API note to each of these classes I don't prefer keeping top-level classes which are used in one place only. The getter/setters seem to be just noise. They may give us some flexibility in the future but in this case that might not be needed? What do you think? > FacetComponent helper classes are package restricted > > > Key: SOLR-748 > URL: https://issues.apache.org/jira/browse/SOLR-748 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 >Reporter: Wojtek Piaseczny >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: 748.patch, SOLR-748.patch, SOLR-748.patch, SOLR-748.patch > > > Original discussion: > http://www.nabble.com/Package-Access-Issues---Extending-FacetComponent-to19148122.html > The FacetComponent class uses several helper classes that currently have > package-restricted access. This makes it impossible to extend the > FacetComponent without rewriting most of its functionality. > A proposed solution is to make those classes public and make their public > member variables accessibly only through get and set functions (i.e. make > them private). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: opening a searcher lazily
There was a deadlock issue originally when the searcher was loaded lazily. That is when we introduced the getNewestSearcher() method in SolrCore On Tue, Apr 28, 2009 at 11:43 PM, Chris Hostetter wrote: > > : is it required to open the searcher in the constructor of SolrCore?. > : We have a usecase where we just open a SolrCore to write a document > : and close it. Opening the searcher is proving to be quite expensive > : for us. > > Hmmm... i suspect it was setup that way initially because "add" required > a searcher to check for an existing doc to delete first. conceptually we > should be able to change the SolrCore so a searcher is only opened once > needed -- but practically this may be a challenge ... i believe there are > more then a few places where an assumtion is made about there being at > least one open searcher. > > > > -Hoss > > -- --Noble Paul
Re: [Solr Wiki] Update of "DataImportHandler" by FergusMcMenemie
Hi Fergus, it is not a good idea to change the documentation now.
Because most of the users would be using Solr1.3 and if they follow
the wiki they will get an error. We should just add the documentation
(w/o removing the HttpdataSource documentation)for URLDataSource and
explicitly say that it is a Solr1.4 feature
after 1.4 release we can change it
On Wed, Apr 29, 2009 at 10:31 PM, Apache Wiki wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Solr Wiki" for change
> notification.
>
> The following page has been changed by FergusMcMenemie:
> http://wiki.apache.org/solr/DataImportHandler
>
> The comment on the change is:
> Adjusting page for new URLDataSource and the deprecation of HTTPdataSource
>
> --
> * The datasource configuration can be done in solr config xml
> [#solrconfigdatasource also]
> * The attribute 'type' specifies the implementation class. It is optional.
> The default value is `'JdbcDataSource'`
> * The attribute 'name' can be used if there are [#multipleds multiple
> datasources] used by multiple entities
> - * All other attributes in the tag are arbitrary. It is
> decided by the !DataSource implementation. [#jdbcdatasource See here] for
> attributes used by !JdbcDataSource and [#httpds see here] for !HttpDataSource
> + * All other attributes in the tag are arbitrary. It is
> decided by the !DataSource implementation. [#jdbcdatasource See here] for
> attributes used by !JdbcDataSource and [#httpds see here] for !URLDataSource
> * [#datasource See here] for plugging in your own
> [[Anchor(multipleds)]]
> === Multiple DataSources ===
> @@ -316, +316 @@
>
>
> = Usage with XML/HTTP Datasource =
> DataImportHandler can be used to index data from HTTP based data sources.
> This includes using indexing from REST/XML APIs as well as from RSS/ATOM
> Feeds.
> +
> [[Anchor(httpds)]]
> - == Configuration of HttpDataSource ==
> + == Configuration of !URLDataSource ==
>
> - A sample configuration in for !HttpdataSource in data config xml looks like
> this
> + A sample configuration in for !URLDataSource in data config xml looks like
> this
> {{{
> - http://host:port/";
> encoding="UTF-8" connectionTimeout="5000" readTimeout="1"/>
> + http://host:port/";
> encoding="UTF-8" connectionTimeout="5000" readTimeout="1"/>
> }}}
> ''' The attributes are '''
>
> @@ -358, +359 @@
>
> }}}
>
>
> - == HttpDataSource Example ==
> + == URLDataSource Example ==
>
> Download the full import example given in the DB section to try this out.
> We'll try indexing the [http://rss.slashdot.org/Slashdot/slashdot Slashdot
> RSS feed] for this example.
>
> @@ -366, +367 @@
>
> The data-config for this example looks like this:
> {{{
>
> -
> +
>
> pk="link"
> @@ -714, +715 @@
>
> == EntityProcessor ==
> Each entity is handled by a default Entity processor called
> !SqlEntityProcessor. This works well for systems which use RDBMS as a
> datasource. For other kind of datasources like REST or Non Sql datasources
> you can choose to extend this abstract class
> `org.apache.solr.handler.dataimport.Entityprocessor`. This is designed to
> Stream rows one by one from an entity. The simplest way to implement your own
> !EntityProcessor is to extend !EntityProcessorBase and override the `public
> Map nextRow()` method.
> '!EntityProcessor' rely on the !DataSource for fetching data. The return
> type of the !DataSource is important for an !EntityProcessor. The built-in
> ones are,
> +
> === SqlEntityProcessor ===
> This is the defaut. The !DataSource must be of type
> `DataSource>>` . !JdbcDataSource can be used
> with this.
> +
> === XPathEntityProcessor ===
> - Used for XML type datasource. The !DataSource must be of type
> `DataSourec` . !HttpDataSource or !FileDataSource can be used with
> this.
> + Used when indexing XML type data. The !DataSource must be of type
> `DataSourec` . !URLDataSource or !FileDataSource is commonly used
> with !XPathEntityProcessor.
> +
> === FileListEntityProcessor ===
> A simple one which can be used to enumerate the list of files from a File
> System based on some criteria. It does not use a !DataSource. The entity
> attributes are:
> *'''`fileName`''' :(required) A regex pattern to identify files
> @@ -801, +805 @@
>
> {{{
> public class JdbcDataSource extends DataSource>>
> }}}
> -
> It is designed to iterate rows in DB one by one. A row is represented as a
> Map.
> +
> - === HttpDataSource ===
> + === URLDataSource ===
> - This is used by X!PathEntityProcessor to fetch content from
> HttpDataSources. See the documentation [#httpds here] . The signature is as
> follows
> + This datasource is often used with X!PathEntityProcessor to fetch content
> from an underlying file:// or http:// location. See the documentation
> [#httpds here] . Th
[jira] Commented: (SOLR-1116) Add a Binary FieldType
[ https://issues.apache.org/jira/browse/SOLR-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704464#action_12704464 ] Noble Paul commented on SOLR-1116: -- bq.We could use base64 as the standard for input/output in text protocols I thought of it. But we will need to add some external library to do base64 encode<->decode . Which one to use? There is one other challenge. The xml response format does not have a binary type . for backcompat reasons I have used as the type. To add another type we may need to bump up the version > Add a Binary FieldType > -- > > Key: SOLR-1116 > URL: https://issues.apache.org/jira/browse/SOLR-1116 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1116.patch, SOLR-1116.patch > > > Lucene supports binary data for field but Solr has no corresponding field > type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-629) Fuzzy search with DisMax request handler
[ https://issues.apache.org/jira/browse/SOLR-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704450#action_12704450 ] Chris Williams commented on SOLR-629: - Hi, FYI: the patch didn't seem to apply cleanly on 1.3, but worked fine on 1.4 Anyways, I'm having some trouble with this patch. It doesn't seem to respect any of my query filters. For example, I have a dismax query where q=the game where qf = 'title_words~.06' where my 'title_words' field is: I get this as the parsed query: "parsedquery_toString"=>"+(((title_words:the~0.6)~0.01 (title_words:game~0.6)~0.01)~2) ()" (I don't want it running anything on the word 'the' because its a stop word) Yet if I change qf to just 'title_words' and remove the fuzziness, same query text, I get this: "parsedquery_toString"=>"+(((title_words:game)~0.01)~1) ()" (which is what I want) > Fuzzy search with DisMax request handler > > > Key: SOLR-629 > URL: https://issues.apache.org/jira/browse/SOLR-629 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Guillaume Smet >Priority: Minor > Attachments: dismax_fuzzy_query_field.v0.1.diff, > dismax_fuzzy_query_field.v0.1.diff > > > The DisMax search handler doesn't support fuzzy queries which would be quite > useful for our usage of Solr and from what I've seen on the list, it's > something several people would like to have. > Following this discussion > http://markmail.org/message/tx6kqr7ga6ponefa#query:solr%20dismax%20fuzzy+page:1+mid:c4pciq6rlr4dwtgm+state:results > , I added the ability to add fuzzy query field in the qf parameter. I kept > the patch as conservative as possible. > The syntax supported is: fieldOne^2.3 fieldTwo~0.3 fieldThree~0.2^-0.4 > fieldFour as discussed in the above thread. > The recursive query aliasing should work even with fuzzy query fields using a > very simple rule: the aliased fields inherit the minSimilarity of their > parent, combined with their own one if they have one. > Only the qf parameter support this syntax atm. I suppose we should make it > usable in pf too. Any opinion? > Comments are very welcome, I'll spend the time needed to put this patch in > good shape. > Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Best way to gather span/token positions from query?
Hello, I'm trying to find a decent approach for getting token positions out of (or is that into?) solr query results. Is the best approach to extend a QueryComponent and/or HighlightComponent? I'm new to solr, and still on fairly shaky ground soany pointers or suggestions are quite welcome. As a little BACKGROUND: I am trying to migrate a custom lucene-only content anaylsys project to solr. The 'old' system programmatically runs a few thousand predefined queries against a corpus, and then analyzes the results. The lucene score is good, but the actual position of the hits is also quite important. My previous system did a simple query parsing to create SpanQuerys, and then used a modified dumpSpans() to get the token position from the spans. Now I am trying to find how to use solr's goodness (and MemoryIndex approach?) to get the span positions in a more logical manner. I think the answer is in the highlighter, but I'm getting a little twisted around, and could use a pointer. I am using a recent Solr nightly snapshot, grails, Aduna Aperture, and Intellij (if any of that matters) Thanks, Sean
[jira] Updated: (SOLR-1135) snapshot is created in the directory where solr was lauched
[ https://issues.apache.org/jira/browse/SOLR-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jianhan updated SOLR-1135: -- Attachment: SOLR-1135.patch upload a patch > snapshot is created in the directory where solr was lauched > --- > > Key: SOLR-1135 > URL: https://issues.apache.org/jira/browse/SOLR-1135 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 1.4 > Environment: Mac OS 10.5 >Reporter: Jianhan >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1135.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > when a request > http://master_host:port/solr/replication?command=snapshoot > is made, a snapshot is created successfully but in a wrong directory. It is > not in the data directory (like the script did) but in the directory where > solr is launched. This creates complication to backup process because this > makes the location of snapshot essential undefined, i.e. depends on how solr > is launched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1135) snapshot is created in the directory where solr was lauched
snapshot is created in the directory where solr was lauched --- Key: SOLR-1135 URL: https://issues.apache.org/jira/browse/SOLR-1135 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 1.4 Environment: Mac OS 10.5 Reporter: Jianhan Priority: Minor Fix For: 1.4 when a request http://master_host:port/solr/replication?command=snapshoot is made, a snapshot is created successfully but in a wrong directory. It is not in the data directory (like the script did) but in the directory where solr is launched. This creates complication to backup process because this makes the location of snapshot essential undefined, i.e. depends on how solr is launched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1116) Add a Binary FieldType
[ https://issues.apache.org/jira/browse/SOLR-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704284#action_12704284 ] Mike Klaas commented on SOLR-1116: -- +1 for url-safe base64 (-_ being the extra chars) > Add a Binary FieldType > -- > > Key: SOLR-1116 > URL: https://issues.apache.org/jira/browse/SOLR-1116 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1116.patch, SOLR-1116.patch > > > Lucene supports binary data for field but Solr has no corresponding field > type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1116) Add a Binary FieldType
[ https://issues.apache.org/jira/browse/SOLR-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704258#action_12704258 ] Ryan McKinley commented on SOLR-1116: - Perhaps we could use a url safe option too... this would let use query binary fields with our existing interfaces. Check: http://iharder.sourceforge.net/current/java/base64/ http://iharder.sourceforge.net/current/java/base64/api/Base64.html#URL_SAFE That refers to RFC3548 > Add a Binary FieldType > -- > > Key: SOLR-1116 > URL: https://issues.apache.org/jira/browse/SOLR-1116 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1116.patch, SOLR-1116.patch > > > Lucene supports binary data for field but Solr has no corresponding field > type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
snapshoot is created in the directory where solr is launched
Hi,
I would like to create a patch for this, but I am new here, and how do I
create a bug for it in Jira?
Thanks,
Jianhan
-- Forwarded message --
From: Jian Han Guo
Date: Tue, Apr 28, 2009 at 10:43 AM
Subject: Re: fail to create or find snapshoot
To: solr-u...@lucene.apache.org
I think this is a bug.
I looked at the classes SnapShooter, and it's constructor looks like this:
public SnapShooter(SolrCore core) {
solrCore = core;
}
This leaves the variable snapDir to be null, and the variable is never
initialized elsewhere, and later in the function SnapShooter.createSnapshot,
the line
snapShotDir = new File(snapDir, directoryName);
is equivalent to
snapShotDir = new File(directoryName);
because snapDir is null, and therefor the snapshot is created in the
directory where the application is launched. A line should be added to the
contructor like this:
public SnapShooter(SolrCore core) {
solrCore = core;
snapDir = core.getDataDir();
}
This is not a problem during development, but it is when you want to deploy
the application to different environments and to schedule snapshot for
backup. Can somebody take a look at this problem?
Thanks,
Jianhan
On Mon, Apr 27, 2009 at 12:02 PM, Jian Han Guo wrote:
> Actually, I found the snapshot in the directory where solr was lauched. Is
> this done on purpose? shouldn't it be in the data directory?
>
> Thanks,
>
> Jianhan
>
>
>
> On Mon, Apr 27, 2009 at 11:43 AM, Jian Han Guo wrote:
>
>> Hi,
>>
>> According to Solr's wiki page http://wiki.apache.org/solr/SolrReplication,
>> if I send the following request to master, a snapshoot will be created
>>
>> http://master_host:port/solr/replication?command=snapshoot
>>
>>
>> But after I did it, nothing seemed happening.
>>
>> I got this response back,
>>
>>
>>
>> 0> name="QTime">2
>>
>>
>> and I checked the data directory, no snapshoot was created.
>>
>> I am not sure what to expect after making the request, and where to find
>> the snapshoot files (and what they are).
>>
>> Thanks,
>>
>> Jianhan
>>
>>
>>
>>
>>
>>
>
[jira] Commented: (SOLR-1116) Add a Binary FieldType
[ https://issues.apache.org/jira/browse/SOLR-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704192#action_12704192 ] Yonik Seeley commented on SOLR-1116: We could use base64 as the standard for input/output in text protocols - that will only expand the size by 33% over binary. > Add a Binary FieldType > -- > > Key: SOLR-1116 > URL: https://issues.apache.org/jira/browse/SOLR-1116 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1116.patch, SOLR-1116.patch > > > Lucene supports binary data for field but Solr has no corresponding field > type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704167#action_12704167 ] Domingo Gómez García commented on SOLR-236: --- -XX:PermSize=1524m -XX:MaxPermSize=1524m -Xmx128m It's not a real fix, but works for now... > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller > Fix For: 1.5 > > Attachments: collapsing-patch-to-1.3.0-dieter.patch, > collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, > collapsing-patch-to-1.3.0-ivan_3.patch, > field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, > field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, > field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch, solr-236.patch, SOLR-236_collapsing.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704162#action_12704162 ] Oleg Gnatovskiy commented on SOLR-236: -- How did you fix the memory issue? > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller > Fix For: 1.5 > > Attachments: collapsing-patch-to-1.3.0-dieter.patch, > collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, > collapsing-patch-to-1.3.0-ivan_3.patch, > field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, > field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, > field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch, solr-236.patch, SOLR-236_collapsing.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701862#action_12701862 ] Domingo Gómez García edited comment on SOLR-236 at 4/29/09 6:46 AM: I made checkout on svn release-1.3.0 and applied SOLR-236_collapsing.patch. Is there any way of integrate with solrj? was (Author: dgomezca): I made checkout on svn release-1.3.0 and applied SOLR-236_collapsing.patch. When I use collapse parameters I always get permgen exceptions. How much memory could use collapse vs normal querys? > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller > Fix For: 1.5 > > Attachments: collapsing-patch-to-1.3.0-dieter.patch, > collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, > collapsing-patch-to-1.3.0-ivan_3.patch, > field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, > field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, > field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch, solr-236.patch, SOLR-236_collapsing.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1134) How to use solrsharp in vb.net to search for the solr index
[ https://issues.apache.org/jira/browse/SOLR-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-1134. - Resolution: Invalid Brindha, please ask the question on the solr-user mailing list. http://lucene.apache.org/solr/mailing_lists.html > How to use solrsharp in vb.net to search for the solr index > --- > > Key: SOLR-1134 > URL: https://issues.apache.org/jira/browse/SOLR-1134 > Project: Solr > Issue Type: Wish > Components: search >Affects Versions: 1.3 > Environment: VB.NET >Reporter: Brindha >Priority: Critical > Original Estimate: 96h > Remaining Estimate: 96h > > I have to search for a solr index and retrieve it using vb.net. I dint have > idea of how to do it.I have to use solrsharp or solrnet. Please guide me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-748) FacetComponent helper classes are package restricted
[ https://issues.apache.org/jira/browse/SOLR-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-748: -- Assignee: Shalin Shekhar Mangar (was: Erik Hatcher) > FacetComponent helper classes are package restricted > > > Key: SOLR-748 > URL: https://issues.apache.org/jira/browse/SOLR-748 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 >Reporter: Wojtek Piaseczny >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: 748.patch, SOLR-748.patch, SOLR-748.patch, SOLR-748.patch > > > Original discussion: > http://www.nabble.com/Package-Access-Issues---Extending-FacetComponent-to19148122.html > The FacetComponent class uses several helper classes that currently have > package-restricted access. This makes it impossible to extend the > FacetComponent without rewriting most of its functionality. > A proposed solution is to make those classes public and make their public > member variables accessibly only through get and set functions (i.e. make > them private). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1021) NullPointerException(s) in SolrJ when using stats and result set is empty
[ https://issues.apache.org/jira/browse/SOLR-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704082#action_12704082 ] Shalin Shekhar Mangar commented on SOLR-1021: - This might have been fixed by Ryan in revision r763791. Can somebody use a recent nightly (or trunk) and confirm? > NullPointerException(s) in SolrJ when using stats and result set is empty > - > > Key: SOLR-1021 > URL: https://issues.apache.org/jira/browse/SOLR-1021 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.4 > Environment: Tomcat 6, Windows >Reporter: Arie Fishler >Priority: Minor > Fix For: 1.4 > > Attachments: QueryResponse.java, SOLR-1021.patch > > > A NullPointerException is thrown at line 51 of class FieldStatsInfo since the > returned stats information for the fname (ctor variable) is null and not > checked for being so. > Seems like this occurs when the search returns with no results but there were > some setGetFieldStatistics defined for some fields. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1116) Add a Binary FieldType
[ https://issues.apache.org/jira/browse/SOLR-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1116: - Attachment: SOLR-1116.patch * mask the byte to get a +ve int * implement toExternal() > Add a Binary FieldType > -- > > Key: SOLR-1116 > URL: https://issues.apache.org/jira/browse/SOLR-1116 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1116.patch, SOLR-1116.patch > > > Lucene supports binary data for field but Solr has no corresponding field > type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-926) Exception in Replication
[ https://issues.apache.org/jira/browse/SOLR-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-926. Resolution: Duplicate Duplicate of SOLR-997 > Exception in Replication > > > Key: SOLR-926 > URL: https://issues.apache.org/jira/browse/SOLR-926 > Project: Solr > Issue Type: Bug > Components: replication (java) >Reporter: Noble Paul > Fix For: 1.4 > > > While running the replication testcase (TestReplicationHandler) > I get an exception > Dec 17, 2008 6:22:12 PM org.apache.solr.common.SolrException log > SEVERE: java.util.concurrent.RejectedExecutionException > at > java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477) > at > java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384) > at > java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856) > at > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45) > at > java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1175) > at > org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:350) > at org.apache.solr.handler.SnapPuller.doCommit(SnapPuller.java:369) > at org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:278) > at > org.apache.solr.handler.ReplicationHandler.doSnapPull(ReplicationHandler.java:211) > at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:138) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) > at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) > at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701862#action_12701862 ] Domingo Gómez García edited comment on SOLR-236 at 4/29/09 4:29 AM: I made checkout on svn release-1.3.0 and applied SOLR-236_collapsing.patch. When I use collapse parameters I always get permgen exceptions. How much memory could use collapse vs normal querys? was (Author: dgomezca): I made checkout on svn release-1.3.0 and applied SOLR-236_collapsing.patch. I have upgraded from 1.2 to 1.3.0 (patched) and I get a lot of permgen exceptions. Specially in calls from solrj. > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller > Fix For: 1.5 > > Attachments: collapsing-patch-to-1.3.0-dieter.patch, > collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, > collapsing-patch-to-1.3.0-ivan_3.patch, > field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, > field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, > field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch, solr-236.patch, SOLR-236_collapsing.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701862#action_12701862 ] Domingo Gómez García edited comment on SOLR-236 at 4/29/09 4:23 AM: I made checkout on svn release-1.3.0 and applied SOLR-236_collapsing.patch. I have upgraded from 1.2 to 1.3.0 (patched) and I get a lot of permgen exceptions. Specially in calls from solrj. was (Author: dgomezca): I made checkout on svn release-1.3.0 and applied SOLR-236_collapsing.patch. After the task "generate-maven-artifacts" I use the resulting distribution and made http://localhost:8983/solr/select/?q=*:*&collapse.field=cat&collapse.max=1&collapse.type=normal (from wiki). No collapsed results. It seems to be ignoring CollapseComponent or something like that. Do I have to configure something else? Could anyone bring to me a working version/patch? Thank you. > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller > Fix For: 1.5 > > Attachments: collapsing-patch-to-1.3.0-dieter.patch, > collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, > collapsing-patch-to-1.3.0-ivan_3.patch, > field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, > field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, > field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch, solr-236.patch, SOLR-236_collapsing.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1127) allow field name to be templatized
[
https://issues.apache.org/jira/browse/SOLR-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-1127.
-
Resolution: Fixed
Assignee: Shalin Shekhar Mangar
Committed revision 769751.
Thanks Noble!
> allow field name to be templatized
> --
>
> Key: SOLR-1127
> URL: https://issues.apache.org/jira/browse/SOLR-1127
> Project: Solr
> Issue Type: New Feature
> Components: contrib - DataImportHandler
>Reporter: Noble Paul
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-1127.patch, SOLR-1127.patch
>
>
> allow templates in field name
> {code:xml}
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1127) allow field name to be templatized
[
https://issues.apache.org/jira/browse/SOLR-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-1127:
Attachment: SOLR-1127.patch
Added a test case.
I'll commit this shortly.
> allow field name to be templatized
> --
>
> Key: SOLR-1127
> URL: https://issues.apache.org/jira/browse/SOLR-1127
> Project: Solr
> Issue Type: New Feature
> Components: contrib - DataImportHandler
>Reporter: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1127.patch, SOLR-1127.patch
>
>
> allow templates in field name
> {code:xml}
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1134) How to use solrsharp in vb.net to search for the solr index
[ https://issues.apache.org/jira/browse/SOLR-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704064#action_12704064 ] Brindha commented on SOLR-1134: --- I have to complete it today.Please help me -- Regards, Brindha.KR > How to use solrsharp in vb.net to search for the solr index > --- > > Key: SOLR-1134 > URL: https://issues.apache.org/jira/browse/SOLR-1134 > Project: Solr > Issue Type: Wish > Components: search >Affects Versions: 1.3 > Environment: VB.NET >Reporter: Brindha >Priority: Critical > Original Estimate: 96h > Remaining Estimate: 96h > > I have to search for a solr index and retrieve it using vb.net. I dint have > idea of how to do it.I have to use solrsharp or solrnet. Please guide me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SOLR-1134) How to use solrsharp in vb.net to search for the solr index
This does not have to be an issue in JIRA. This can be a question in the mailing list. BTW solrsharp is not a part of this project On Wed, Apr 29, 2009 at 3:56 PM, Brindha (JIRA) wrote: > How to use solrsharp in vb.net to search for the solr index > --- > > Key: SOLR-1134 > URL: https://issues.apache.org/jira/browse/SOLR-1134 > Project: Solr > Issue Type: Wish > Components: search > Affects Versions: 1.3 > Environment: VB.NET > Reporter: Brindha > Priority: Critical > > > I have to search for a solr index and retrieve it using vb.net. I dint have > idea of how to do it.I have to use solrsharp or solrnet. Please guide me. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- --Noble Paul
[jira] Created: (SOLR-1134) How to use solrsharp in vb.net to search for the solr index
How to use solrsharp in vb.net to search for the solr index --- Key: SOLR-1134 URL: https://issues.apache.org/jira/browse/SOLR-1134 Project: Solr Issue Type: Wish Components: search Affects Versions: 1.3 Environment: VB.NET Reporter: Brindha Priority: Critical I have to search for a solr index and retrieve it using vb.net. I dint have idea of how to do it.I have to use solrsharp or solrnet. Please guide me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is back to normal: Solr-trunk #787
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/787/changes
