[
https://issues.apache.org/jira/browse/SOLR-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Ludington updated SOLR-494:
Attachment: multicoreupdate.patch
In a multicore setting, these changes cause the LukeRequestHandler
[
https://issues.apache.org/jira/browse/SOLR-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Ludington reopened SOLR-494:
-
I finally had occasion to look at this in a multicore setting, and the extra
core-identifying field
It appears the problem is in the addition of a List of Maps to the
LukeRequestHandler output. This results in XML like the following:
synonyms.txt
true
true
org.apache.solr.analysis.SynonymFilterFactory
...
and that empty seems to be causing the problem
[
https://issues.apache.org/jira/browse/SOLR-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579614#action_12579614
]
Greg Ludington commented on SOLR-494:
-
The LukeRequestHandler output (and IndexSc
[
https://issues.apache.org/jira/browse/SOLR-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Ludington updated SOLR-494:
Attachment: Field View.jpg
Screen shot of the basic view of the "text" field from the exam
[
https://issues.apache.org/jira/browse/SOLR-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Ludington updated SOLR-494:
Attachment: jsonschemabrowser.patch
This patch consists of 5 files:
1) Changes to IndexSchema to
Environment: N/A
Reporter: Greg Ludington
Priority: Minor
Fix For: 1.3
This patch submits a schema browsing tool based on making Ajax calls to
LukeRequestHandler. It is in progress, but far enough along to generate
discussion and see if people find it useful
I started looking through this, and it looks very nice, though I do
see one slight nit to pick. I may be reading this incorrectly, but
two parameters in rangeCount appear to be transposed. In
SimpleFacets.java, the rangeCount method uses:
new ConstantScoreRangeQuery(field,low,high,iHigh,iLow)
b
[
https://issues.apache.org/jira/browse/SOLR-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Ludington updated SOLR-181:
Attachment: solr-181-required-fields.patch
This patch allows a per-field "required" pro
Support for "Required" field Property
-
Key: SOLR-181
URL: https://issues.apache.org/jira/browse/SOLR-181
Project: Solr
Issue Type: Improvement
Components: update
Repo
-- although only the "weight" field has both
-- but it does not expect analyzers or any child node to be overriden,
only attributes. Let me know if this assumption is correct, as well
as any other thoughts on the sample.
Thanks,
Greg
On 12/11/06, Greg Ludington <[EMAIL PROT
[ http://issues.apache.org/jira/browse/SOLR-75?page=all ]
Greg Ludington updated SOLR-75:
---
Attachment: schemav2sample.zip
An updated sample, including feedback about fieldtype->field inheritance. It
presumes that:
a) a field can inherit any attrib
: What about creating an xml report (using a the live index searcher)
: and transforming that with XSLT to add look&feel?
yeah ... i think you've really got something totally usable as is right
now, os don't feel like you have to start over. when i first typed up
I do not have any real prefere
Yes, it makes more sense, but I might go back to the drawing board for
a bit -- this sort of inheritance gets ugly in XSL. Assuming there
are the appropriate public methods, it might be better to work
directly against the live IndexSchema rather than by XSLT transforming
the schema.xml file. The
Taking this off the list for a moment, because I may be a bit obtuse here:
(And, apparently so obtuse I negelcted to change the to: field. Such
things happen late after a launch night.)
i think it would definitely be helpful ... showing the inherited
attributes "inline" is really what would make using the schema
browser worth while (as opposed to just reading hte XML directly) ... it
saves the confusion of looking at the field, then clicking over to the
fieldtype to see what it i
yeah .. i wasn't sure if this version was identicle or not, it sounds like
you added some stuff, but the key thing i was refering to was what
when showing a "field" we should display both the direct attributes as
well as any attributes it inherits from it's "fieldtype"
Currently, there is "usage
[
http://issues.apache.org/jira/browse/SOLR-75?page=comments#action_12456285 ]
Greg Ludington commented on SOLR-75:
(Sent in email earlier, but adding it to the JIRA issue proper)
I do not know if you have seen the update, as opposed to the
es.apache.org/jira/browse/SOLR-75
> Project: Solr
> Issue Type: New Feature
> Components: web gui
> Environment: any
>Reporter: Greg Ludington
>Priority: Minor
> Attachments: closed.gif, open.gif, solr75v1.diff
>
[ http://issues.apache.org/jira/browse/SOLR-75?page=all ]
Greg Ludington updated SOLR-75:
---
Attachment: solr75v1.diff
closed.gif
open.gif
XSLT and jsp changes to allow schema.xml to be explored via a DHTML tree
widget, with
nment: any
Reporter: Greg Ludington
Priority: Minor
The files in this upcoming patch create a simple "schema browser" for the admin
tool. It serves schema.xml along with a stylesheet that in compliant browsers
creates a page with a tree widget to show the field
[ http://issues.apache.org/jira/browse/SOLR-58?page=all ]
Greg Ludington updated SOLR-58:
---
Attachment: schemaxsl.zip
This may be slightly OT for this issue, but since the ticket discusses XSLT in
the browser, and the Self Service wiki page, I though to
I definitely think we want to support stuff like this out of the box in
the long run, i think it just needs to be based on specifying the Facet
info in a more robust way (ie: XML configuration)
Not to threadjack, but this is actually the path I went down during my
faceting prototype, pushing al
init/query params -- but as i type this, it occurs to me that one approach
would be to allow for "per field" usages of the of the "facet.query" param
to specify queries that would use a SolrQueryParser with the default
field set to the specified field, so that you could things like...
fac
I'd like to get some feedback on the overall appraoch and params before i
proceed too much farther.
These comments are probably just confusion since the approach differs
from my home-grown faceting prototype, and my dev box is on a moving
truck right now, so I cannot try the patch, so please be
methods do not accept flags, can cause NPE when
writing output
: >
--
: >
: > Key: SOLR-39
: > URL: http://issues.apache.org/jira/browse/SOLR-39
: > Project: Solr
: >
[ http://issues.apache.org/jira/browse/SOLR-39?page=all ]
Greg Ludington updated SOLR-39:
---
Attachment: SolrIndexSearcherdocListAndSet.patch
> Searcher's getDocListAndSet methods do not accept flags, can cause NPE when
> wri
LR-39
Project: Solr
Issue Type: Bug
Components: search
Reporter: Greg Ludington
Priority: Minor
Attachments: SolrIndexSearcherdocListAndSet.patch
SolrIndexSearcher's getDocListAndSet methods do not accept flags, which can, in
some cases, ca
Don't let me discourage you from having a "FacetHandler" interface that
supports generic faceting functionality using different rules (ie:
I don't get discouraged -- I just take advice from smart people when
they offer it :). I still do have my generic Facet handling
mechanism, because the Face
After thinking over your comments, I removed the facetHandler
completely, instead loading the Facets into a plain user cache, and
put the output work in a utils class similar to SolrPluginUtils. It
complicates the Term caching for me slightly, but it allows me to add
a "FacetUtils.doStandardFacet
that's a very good way to do it. You could also use
SolrIndexSearcher.numDocs -- it is esentially the same thing, but in the
future there may be optimizations that can be done to eliminate the
construction of one DocSet (if the other one already exists)
Thank you for the tip -- I will take a lo
I have implemented faceted browsing in prototype I have been working
on with Solr, but I would like to ask some more experienced hands
about performance implications. Currently, I calculate the count of
a given facet as follows:
DocSet valueDocSet = req.getSearcher().getDocSet(item.getQue
[ http://issues.apache.org/jira/browse/SOLR-6?page=comments#action_12419801
]
Greg Ludington commented on SOLR-6:
---
Wonky is the correct word -- if the border-left is one pixel, it shows as
white. If it is two pixels, the color shows. A border-right
[ http://issues.apache.org/jira/browse/SOLR-6?page=all ]
Greg Ludington updated SOLR-6:
--
Attachment: iestyles.patch
The visual differences occur because IE 6 (I do not have IE7 to test) does not
seem to apply border to rows, only to cells, and also does
34 matches
Mail list logo
