Oops! Sorry, I thought shard and core were one in the same and the
terms could be used interchangeably - I've got a multicore setup which
I'm able to search across by using the shards parameter. I think
you're right, that *is* the question I was asking.
Thanks for letting me know it's not
How are you querying the core to begin with?
On Dec 16, 2010, at 6:46 AM, Mark Allan wrote:
Hi all,
I've been bashing my head against the wall for a few hours now,
trying to get mlt (more-like-this) queries working across multiple
cores. I've since seen a JIRA issue and documentati
Hi all,
I've been bashing my head against the wall for a few hours now, trying
to get mlt (more-like-this) queries working across multiple cores.
I've since seen a JIRA issue and documentation saying that multicore
doesn't yet support mlt queries. Oops!
Anyway, to get around this, I was
For me, I simply deleted the original email, but I'm now quite
enjoying the irony of the complaints causing more noise on the list
than the original email! ;-)
M
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
This is a response to a thread from several months ago ( http://lucene.472066.n3.nabble.com/mincount-doesn-t-work-with-FacetQuery-tp473162p473162.html
) Sorry, I don't know where to get the thread number to request that
specific thread from listserv and reply properly via email.
Anyway, I've
to become released than 1.5.x, which is highly unlikely to be ever
released.
On Thursday 09 September 2010 13:04:38 Mark Allan wrote:
Thanks. Are you suggesting I use branch_3x and is that considered
stable?
Cheers
Mark
On 9 Sep 2010, at 10:47 am, Markus Jelsma wrote:
http://svn.apache.org
Thanks. Are you suggesting I use branch_3x and is that considered
stable?
Cheers
Mark
On 9 Sep 2010, at 10:47 am, Markus Jelsma wrote:
http://svn.apache.org/repos/asf/lucene/dev/branches/
-Original message-
From: Mark Allan
Sent: Thu 09-09-2010 10:44
To: solr-user
Hi all,
As I've mentioned in the past, I've created some custom field types
which make use of the AbstractSubTypeFieldType class in the current
trunk version of solr for a service we're working on. We're getting
close to putting our service into production (early 2011) and we're
now look
If you're storing the timestamp as MMDDHHMM, why don't you make it
a trie-coded integer field (type 'tint') rather than text? That way,
I believe range queries would be more efficient. You can then do a
facet query, specifying your desired ranges as one facet query for
each range.
N
a particular revision that I should go with? Or
should I just
pull trunk and use that, and last of all, is trunk stable enough to
be used
in production?
Regards,
Thomas
On Mon, Aug 9, 2010 at 8:38 AM, Mark Allan
wrote:
On 9 Aug 2010, at 1:01 pm, Otis Gospodnetic wrote:
Mark,
A good way
For what it's worth, London and the rest of the UK is currently
observing British Summer Time (called Daylight Savings Time in other
parts of the world) which is why we appear to be UTC+1 between the
last Sunday in March and the last Sunday in October.
Mark
On 11 Aug 2010, at 12:36 pm, Fre
On 9 Aug 2010, at 1:01 pm, Otis Gospodnetic wrote:
Mark,
A good way to get your changes/improvements into Solr is by putting
them in
JIRA. Please see http://wiki.apache.org/solr/HowToContribute
Thanks!
Otis
Hi Otis,
For the class which requires only minor modifications, I tested it to
I see you have the exact same requirements I did and have also hit the
same problem I did a month-or-so ago. I ended up writing a custom
field type based on solr.schema.PointType and making some very minor
modifications to one of the Solr classes (AbstractSubfieldType) to
allow the field a
On 29 Jul 2010, at 12:27 pm, Gora Mohanty wrote:
On Thu, 29 Jul 2010 10:49:18 +0100
Mark Allan wrote:
[...]
Is there a way to reference each core/shard by name rather than
explicitly stating the host, port and path in the URL? For
example, I'd like to swap:
http://localhost
Hi all,
We're building a service which will have data from a number of
different providers, but the data from each will be slightly
different. We've decided to keep the data separate by using multiple
cores in Solr; one for each provider. There will be enough overlap in
the data to allow
On 28 Jul 2010, at 2:08 pm, MitchK wrote:
Second try to send a mail to the mailing list...
Your first attempt got through as well. Here's my original response.
I think you should just be able to add &wt=json to the end of your
query (or change whatever the existing wt parameter is in your
I think you should just be able to add &wt=json to the end of your
query (or change whatever the existing wt parameter is in your URL).
Mark
On 28 Jul 2010, at 12:54 pm, MitchK wrote:
Hello community,
I need to transform SolrJ - responses into JSON, after some
computing on
those results
Hi Stephan,
On the iPad, as with the iPhone, I'm afraid you're stuck with using
SQLite if you want any form of database in your app.
I suppose if you wanted to get really ambitious and had a lot of time
on your hands you could use Xcode to try and compile one of the open-
source C-based DB
On 7 Jul 2010, at 6:24 pm, Yonik Seeley wrote:
On Wed, Jul 7, 2010 at 8:15 AM, Grant Ingersoll
wrote:
Originally, I had intended that it was just for one Field Sub Type,
thinking that if we ever wanted multiple sub types, that a new,
separate class would be needed
Right - this was my ori
n this way, then
I see no reason not to incorporate it. Besides, I could see
extending PointType, etc. to be NamedPointType, for example.
I'm curious, Mark, how are you searching those fields? What types
of queries are you generating?
-Grant
On Jul 2, 2010, at 9:51 AM, Mark Allan wr
On 3 Jul 2010, at 1:50 am, Chris Hostetter wrote:
: The changes to AbstractSubTypeFieldType do not have any adverse
effects on the
: solr.PointType class, so I'd quite like to suggest it gets
included in the
: main solr source code. Where can I send a patch for someone to
evaluate or
: s
Hi folks,
I've made a few small changes to the AbstractSubTypeFieldType class to
allow users to define distinct field types for each subfield. This
enables us to define complex data types in the schema.
For example, we have our own subclass of the CoordinateFieldType
called TemporalCover
Very nice indeed! That definitely needs to be shouted about in the
docs.
Any way to make it work with facet queries or can dismax requests not
do that? I tried adding a few &facet.query parameters but it came back
with nothing in the facet list.
Mark
On 1 Jul 2010, at 12:36 pm, Erik Hat
anyone wants the code as it is just now, I can happily provide it.
Alternatively, if you think it might be of use to others, I can roll
it back into the org.apache.solr packages and submit it to the
repository so that those with more Solr experience than I can see if
it could be better impleme
ing
is a
patch at the moment. http://wiki.apache.org/solr/FieldCollapsing)
Not sure if this helped you at all, but at the very least it was a
nice
conceptual exercise ;-)
Cheers,
Geert-Jan
2010/6/22 Mark Allan
Hi all,
Firstly, I apologise for the length of this email but I need to
de
Hi all,
Firstly, I apologise for the length of this email but I need to
describe properly what I'm doing before I get to the problem!
I'm working on a project just now which requires the ability to store
and search on temporal coverage data - ie. a field which specifies a
date range durin
On 16 Apr 2009, at 9:00 am, Shalin Shekhar Mangar wrote:
On Thu, Apr 16, 2009 at 1:20 PM, Mark Allan
wrote:
My thinking is that Solr is trying to add the field directly as
'1953'
before doing the text factory stuff and is therefore not in the
right format
for indexing. Does
Hi all,
I'm encountering a problem when I try to add records with a date field
to the index.
The records I'm adding have very little date precision, usually
MMDD but some only have year and month, others only have a year.
I'm trying to get around this by using a text pattern factory
28 matches
Mail list logo