[jira] Commented: (SOLR-20) A simple Java client for updating and searching
[
https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499730
]
Ben Incani commented on SOLR-20:
The SolrClientImpl does not implement the following optional attributes for
add as documented in http://wiki.apache.org/solr/UpdateXmlMessages
allowDups = true | false — default is false
overwritePending = true | false — default is negation of allowDups
overwriteCommitted = true|false — default is negation of allowDups
Attached is patch for SolrClientImpl.java which implements allowDups.
*** SolrClientImpl.java.patch ***
48a49,55
/**
* Optional attributes for add
*/
protected boolean allowDups;
protected boolean overwritePending;// TODO: not implemented
protected boolean overwriteCommitted; // TODO: not implemented
86a94,97
public SolrClientImpl(URL baseURL) throws Exception {
this(baseURL, false);
}
91a103
* @param allowDups allow duplicates to be added to the index
95c107
public SolrClientImpl(URL baseURL) throws Exception
---
public SolrClientImpl(URL baseURL, boolean allowDups) throws Exception
103c115
---
this.allowDups = allowDups;
243c255,260
writer.write(add);
---
StringBuffer strAdd = new StringBuffer(add );
if (allowDups == true) {
strAdd.append(allowDups=\true\);
}
strAdd.append();
writer.write(strAdd.toString());
*** SolrClientImpl.java.patch ***
A simple Java client for updating and searching
---
Key: SOLR-20
URL: https://issues.apache.org/jira/browse/SOLR-20
Project: Solr
Issue Type: New Feature
Components: clients - java
Environment: all
Reporter: Darren Erik Vengroff
Priority: Minor
Attachments: DocumentManagerClient.java, DocumentManagerClient.java,
solr-client-java-2.zip.zip, solr-client-java.zip, solr-client-sources.jar,
solr-client.zip, solr-client.zip, solr-client.zip,
solrclient_addqueryfacet.zip, SolrClientException.java,
SolrServerException.java
I wrote a simple little client class that can connect to a Solr server and
issue add, delete, commit and optimize commands using Java methods. I'm
posting here for review and comments as suggested by Yonik.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-20) A simple Java client for updating and searching
[ https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499831 ] Ryan McKinley commented on SOLR-20: --- Hi Ben- Thanks for the patch. Will Johnson added the options to the java client on: http://solrstuff.org/svn/solrj/ This implementation is now quite stable (thanks to lots of help from Will!) and I hope will be integrated into solr trunk shortly after 1.2 (this week?!) About the allowDups/overwritePending/overwriteCommited options... what part of them do you use? In SOLR-60, there is talk of replacing the three options with a (simpler) overwrite=true/false -- maybe we should change the client api to: UpdateResponse add( SolrDocument doc, boolean overwrite ) throws SolrServerException; In anticipation of this change? A simple Java client for updating and searching --- Key: SOLR-20 URL: https://issues.apache.org/jira/browse/SOLR-20 Project: Solr Issue Type: New Feature Components: clients - java Environment: all Reporter: Darren Erik Vengroff Priority: Minor Attachments: DocumentManagerClient.java, DocumentManagerClient.java, solr-client-java-2.zip.zip, solr-client-java.zip, solr-client-sources.jar, solr-client.zip, solr-client.zip, solr-client.zip, solrclient_addqueryfacet.zip, SolrClientException.java, SolrServerException.java I wrote a simple little client class that can connect to a Solr server and issue add, delete, commit and optimize commands using Java methods. I'm posting here for review and comments as suggested by Yonik. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-238) [Patch] The tutorial on our website is against trunk which causes confusion by user
[ https://issues.apache.org/jira/browse/SOLR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499844 ] Yonik Seeley commented on SOLR-238: --- This document is for Apache Solr version 1.1.2007.05.29.11.45.13 That isn't the most user-friendly version string for between releases, but I guess it will serve. [Patch] The tutorial on our website is against trunk which causes confusion by user --- Key: SOLR-238 URL: https://issues.apache.org/jira/browse/SOLR-238 Project: Solr Issue Type: Improvement Components: documentation Reporter: Thorsten Scherler Assignee: Hoss Man Attachments: SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.png The patch will add a note to the tutorial page with the following headsup: This is documentation for the development version (TRUNK). Some instructions may only work if you are working against svn head. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499843 ] Will Johnson commented on SOLR-240: --- i get the stacktrace below with the latest from head with useNativeLocks turned off (from my patch). this took about 2 minutes to reproduce on my windows laptop. one thing i thought of is that local antivirus scanning / backup software which we run here may be getting in the way. i know many other search engines / high performance databases out there have issues with antivirus software because it causes similar locking issues. i'm disabling as much of the IT 'malware' as possible and seeing better results even with default locking however i had everything running when i had good results with the native locking enabled so it still seems to be a good idea to use the patch (or something similar). - will SEVERE: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: [EMAIL PROTECTED] b822c61c394dd5f449aaf5e5717356-write.lock at org.apache.lucene.store.Lock.obtain(Lock.java:70) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:579) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:391) at org.apache.solr.update.SolrIndexWriter.init(SolrIndexWriter.java:81) at org.apache.solr.update.UpdateHandler.createMainIndexWriter(UpdateHandler.java:120) at org.apache.solr.update.DirectUpdateHandler2.openWriter(DirectUpdateHandler2.java:181) at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:259) at org.apache.solr.handler.XmlUpdateRequestHandler.update(XmlUpdateRequestHandler.java:166) at org.apache.solr.handler.XmlUpdateRequestHandler.handleRequestBody(XmlUpdateRequestHandler.java:84) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:79) at org.apache.solr.core.SolrCore.execute(SolrCore.java:658) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:198) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:166) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:835) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:641) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:368) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) java.io.IOException: Lock obtain timed out: SimpleFSLock Key: SOLR-240 URL: https://issues.apache.org/jira/browse/SOLR-240 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2 Environment: windows xp Reporter: Will Johnson Attachments: IndexWriter.patch, IndexWriter2.patch, stacktrace.txt, ThrashIndex.java when running the soon to be attached sample application against solr it will eventually die. this same error has happened on both windows and rh4 linux. the app is just submitting docs with an id in batches of 10, performing a commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ready for release 1.2
It looks to me like we're ready to cut a release. I've tried out Solr on the latest versions of Tomcat/Jetty/Resin... everything looks good. SOLR-238 is about the only other thing to commit AFAIK (and it's optional). I don't think we need to include the clients directory at this point...Solr Flare is still in development, and the python client hasn't been updated (there is a JIRA patch in the works). Please try to make any other little changes within the next few hours, and then I'll start the release process this afternoon (creating branches, snapshots to vote on, etc) baring any objections. In the meantime, I'll be doing some sanity checking such as running RAT to check for licensing issues. -Yonik
Re: ready for release 1.2
Excellent! What are your final thoughts on the NIO issues in SOLR-128? Should we change: New class=org.mortbay.jetty.nio.SelectChannelConnector to: New class=org.mortbay.jetty.bio.SocketConnector or was it just a python client error? Yonik Seeley wrote: It looks to me like we're ready to cut a release. I've tried out Solr on the latest versions of Tomcat/Jetty/Resin... everything looks good. SOLR-238 is about the only other thing to commit AFAIK (and it's optional). I don't think we need to include the clients directory at this point...Solr Flare is still in development, and the python client hasn't been updated (there is a JIRA patch in the works). Please try to make any other little changes within the next few hours, and then I'll start the release process this afternoon (creating branches, snapshots to vote on, etc) baring any objections. In the meantime, I'll be doing some sanity checking such as running RAT to check for licensing issues. -Yonik
Re: ready for release 1.2
On 5/29/07, Ryan McKinley [EMAIL PROTECTED] wrote: What are your final thoughts on the NIO issues in SOLR-128? Should we change: New class=org.mortbay.jetty.nio.SelectChannelConnector to: New class=org.mortbay.jetty.bio.SocketConnector Since it looks like it makes a big difference for Windows, I'd be in favor of switching it (it was normally slightly faster in Unix too, but nothing anyone would notice with real queries). NIO's Use this connector for many frequently idle connections and for threadless continuations doesn't seem to really apply to Solr anyway. or was it just a python client error? On Linux, it looks like it's a sub-optimal python client design, nothing to do with the Solr server. -Yonik
Re: ready for release 1.2
Yonik Seeley wrote: On 5/29/07, Ryan McKinley [EMAIL PROTECTED] wrote: What are your final thoughts on the NIO issues in SOLR-128? Should we change: New class=org.mortbay.jetty.nio.SelectChannelConnector to: New class=org.mortbay.jetty.bio.SocketConnector Since it looks like it makes a big difference for Windows, I'd be in favor of switching it (it was normally slightly faster in Unix too, but nothing anyone would notice with real queries). NIO's Use this connector for many frequently idle connections and for threadless continuations doesn't seem to really apply to Solr anyway. Great. can you commit the config you tested with? adding the performance/platform comments
Re: ready for release 1.2
+1, thanks Yonik! Yeah, the clients directory is still a work in progress. Eventually Flare will be worth distributing with a release, but even then most folks would want it to be installed from a plugin repository (or svn directly). Same with the solr-ruby code, which is already available from RubyForge by gem install solr-ruby, which installs the 0.0.3 version I pushed up there recently. Erik On May 29, 2007, at 1:24 PM, Yonik Seeley wrote: It looks to me like we're ready to cut a release. I've tried out Solr on the latest versions of Tomcat/Jetty/Resin... everything looks good. SOLR-238 is about the only other thing to commit AFAIK (and it's optional). I don't think we need to include the clients directory at this point...Solr Flare is still in development, and the python client hasn't been updated (there is a JIRA patch in the works). Please try to make any other little changes within the next few hours, and then I'll start the release process this afternoon (creating branches, snapshots to vote on, etc) baring any objections. In the meantime, I'll be doing some sanity checking such as running RAT to check for licensing issues. -Yonik
Re: svn commit: r542461 - in /lucene/solr/trunk/src/java/org/apache/solr: schema/IndexSchema.java update/DirectUpdateHandler.java update/UpdateHandler.java
: Now, the only status codes set in SolrExceptions are valid HTTP status codes: : 500 : 400 : 503 : 404 should we deprecate the current SolrException constructor and add one that uses an enumeration of legal HTTP status codes ... that way we can eventually eliminate the current usage of int and get compile time assurances that we only generate legal HTTP status codes. -Hoss
[jira] Resolved: (SOLR-128) Include Newer version of Jetty
[ https://issues.apache.org/jira/browse/SOLR-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-128. Resolution: Fixed Fix Version/s: 1.2 will be included in solr1.2 Include Newer version of Jetty -- Key: SOLR-128 URL: https://issues.apache.org/jira/browse/SOLR-128 Project: Solr Issue Type: Improvement Components: update Reporter: Ryan McKinley Assignee: Ryan McKinley Priority: Minor Fix For: 1.2 Attachments: jetty-6.3-example.zip, Jetty6.config.patch, lib.zip, start.jar It would be good to include an up-to-date jetty version for the example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r542461 - in /lucene/solr/trunk/src/java/org/apache/solr: schema/IndexSchema.java update/DirectUpdateHandler.java update/UpdateHandler.java
Chris Hostetter wrote: : Now, the only status codes set in SolrExceptions are valid HTTP status codes: : 500 : 400 : 503 : 404 should we deprecate the current SolrException constructor and add one that uses an enumeration of legal HTTP status codes ... that way we can eventually eliminate the current usage of int and get compile time assurances that we only generate legal HTTP status codes. I like that... but i'd like to see solr1.2 out first ;)
[jira] Commented: (SOLR-238) [Patch] The tutorial on our website is against trunk which causes confusion by user
[ https://issues.apache.org/jira/browse/SOLR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499882 ] Hoss Man commented on SOLR-238: --- This document is for Apache Solr version 1.1.2007.05.29.11.45.13 That isn't the most user-friendly version string for between releases, but I guess it will serve. Agreed, but specversion needs to be very explicit for the menifest file, and the only other version we have is version -- which is just X.Y-dev between releases. We could add a new versionordate variable, but it's one more thing people would have to explicitly set when doing releases. [Patch] The tutorial on our website is against trunk which causes confusion by user --- Key: SOLR-238 URL: https://issues.apache.org/jira/browse/SOLR-238 Project: Solr Issue Type: Improvement Components: documentation Reporter: Thorsten Scherler Assignee: Hoss Man Attachments: SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.png The patch will add a note to the tutorial page with the following headsup: This is documentation for the development version (TRUNK). Some instructions may only work if you are working against svn head. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r542461 - in /lucene/solr/trunk/src/java/org/apache/solr: schema/IndexSchema.java update/DirectUpdateHandler.java update/UpdateHandler.java
: should we deprecate the current SolrException constructor and add one that : uses an enumeration of legal HTTP status codes ... that way we can : eventually eliminate the current usage of int and get compile time : assurances that we only generate legal HTTP status codes. : : : I like that... but i'd like to see solr1.2 out first ;) i was just thinking it might be good to get the deprecations in 1.2 so it's easier to delete the current one in the next release. -Hoss
[jira] Commented: (SOLR-238) [Patch] The tutorial on our website is against trunk which causes confusion by user
[ https://issues.apache.org/jira/browse/SOLR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499887 ] Yonik Seeley commented on SOLR-238: --- I'm for committing this as-is, unless there are some other tweaks you want to make first. [Patch] The tutorial on our website is against trunk which causes confusion by user --- Key: SOLR-238 URL: https://issues.apache.org/jira/browse/SOLR-238 Project: Solr Issue Type: Improvement Components: documentation Reporter: Thorsten Scherler Assignee: Hoss Man Attachments: SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.png The patch will add a note to the tutorial page with the following headsup: This is documentation for the development version (TRUNK). Some instructions may only work if you are working against svn head. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-238) [Patch] The tutorial on our website is against trunk which causes confusion by user
[ https://issues.apache.org/jira/browse/SOLR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-238. --- Resolution: Fixed Fix Version/s: 1.2 Committed revision 542626. Website_Update_HOWTO and HowToRelease updated to reflect the process tweaks. [Patch] The tutorial on our website is against trunk which causes confusion by user --- Key: SOLR-238 URL: https://issues.apache.org/jira/browse/SOLR-238 Project: Solr Issue Type: Improvement Components: documentation Reporter: Thorsten Scherler Assignee: Hoss Man Fix For: 1.2 Attachments: SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.diff, SOLR-238.png The patch will add a note to the tutorial page with the following headsup: This is documentation for the development version (TRUNK). Some instructions may only work if you are working against svn head. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-249) deprecate SolrException( int, ... ) in favor of SolrException( enum, ... )
deprecate SolrException( int, ... ) in favor of SolrException( enum, ... ) -- Key: SOLR-249 URL: https://issues.apache.org/jira/browse/SOLR-249 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Priority: Minor SolrException should return valid HTTP status codes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Commented: (SOLR-216) Improvements to solr.py
Mike,
I've had my solr.py in production use internally for about a month now.
So, as you can imagine, I've worked through a few oddball bugs that
occasionally pop up. It seems pretty stable for me.
I'm planning to upload a new file attachment to this issue containing my
changes, plus fixing the bug reports that were filed against my open
ticket. But first, a few quick questions
I would prefer to have a complete directory structure (i.e., setup.py,
unit tests, samples, etc) instead of just the solr.py file. Would
anyone see a problem with this?
Also, on some of your comments:
- list comprehensions solely to perform looped execution are harder to parse
and slower than explicitly writing a for loop
List comprehensions seem to be a matter of contention for some.
However, it's a battle I'm not interested in fighting, so changed it to
a for loop.
- shadowing builtins is generally a bad idea
Any shadowing of builtins was unintentional. Did you see specific
examples? I run the code through pychecker and pylint to try to avoid
such cases.
- SolrConnection is an old-style class, but Response is new-style
This was a holdover from the old SolrConnection class I copied from. I'm
fixing this.
functionality:
- why are 'status'/'QTime' returned as floats?
This was just a misunderstanding on my part of what QTime was actually
returning. Fixing.
- all NamedList's appearing in the output are converted to dicts--this loses
information (in particular, it will be unnecessarily hard for the user to use
highlighting/debug data). Using the python/json response format would prevent
this. Not returning highlight/debug data in the standard response format (and
yet providing said parameters in the query() method) seems odd. Am I missing
something? Oh, they are set as dynamic attributes of Response, I see.
Definitely needs documentation.
Yes, this needs to be documented. (Please c.f. to my question about
allowing a complete directory structure.)
- passing fields='' to query() will return all fields, when the desired return
is likely no fields
I've changed the default for fields= to be '*', instead of None or .
This way, passing in 'fields=' will result in 'fl=' being passed to
the backend. However, I still don't see the point, as passing both
'fl=' and 'fl=*' return the exact same set of fields (i.e., all) on my
test setup.
- it might be better to settle on an api that permits doc/field boosts. How
about using a tuple as the field name in the field dict?
conn.add_many([{'id': 1, ('field2', 2.33): usome text}])
doc boosts could be handled by optionally providing the fielddict as a
(fielddict, boost) tuple.
I agree. I was not aware of field boosts at the time. I'll code this change.
- for 2.5+, a cool addition might be:
if sys.version 2.5
import contextlib
def batched(solrconn):
solrconn.begin_batch()
yield solrconn
solrconn.end_batch()
batched = contextlib.contextmanager(batched)
Use as:
with batched(solrconn):
solrconn.add(...)
solrconn.add(...)
solrconn.add(...)
Adding...
[jira] Assigned: (SOLR-216) Improvements to solr.py
[ https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas reassigned SOLR-216: --- Assignee: Mike Klaas Improvements to solr.py --- Key: SOLR-216 URL: https://issues.apache.org/jira/browse/SOLR-216 Project: Solr Issue Type: Improvement Components: clients - python Affects Versions: 1.2 Reporter: Jason Cater Assignee: Mike Klaas Priority: Trivial Attachments: solr.py I've taken the original solr.py code and extended it to include higher-level functions. * Requires python 2.3+ * Supports SSL (https://) schema * Conforms (mostly) to PEP 8 -- the Python Style Guide * Provides a high-level results object with implicit data type conversion * Supports batching of update commands -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (SOLR-216) Improvements to solr.py
[ https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SOLR-216 started by Mike Klaas. Improvements to solr.py --- Key: SOLR-216 URL: https://issues.apache.org/jira/browse/SOLR-216 Project: Solr Issue Type: Improvement Components: clients - python Affects Versions: 1.2 Reporter: Jason Cater Assignee: Mike Klaas Priority: Trivial Attachments: solr.py I've taken the original solr.py code and extended it to include higher-level functions. * Requires python 2.3+ * Supports SSL (https://) schema * Conforms (mostly) to PEP 8 -- the Python Style Guide * Provides a high-level results object with implicit data type conversion * Supports batching of update commands -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-216) Improvements to solr.py
[
https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499913
]
Mike Klaas commented on SOLR-216:
-
On 29-May-07, at 12:41 PM, Jason Cater wrote:
I've had my solr.py in production use internally for about a month now. So, as
you can imagine, I've worked through a few oddball bugs that occasionally pop
up. It seems pretty stable for me.
Yes, I agree that it is looking good. Since we would be replacing the existing
implementation completely, I think that it is worth taking extra care and
examining the api choices carefully so we won't have to replace it or deprecate
things in the near future.
I would prefer to have a complete directory structure (i.e., setup.py, unit
tests, samples, etc) instead of just the solr.py file. Would anyone see a
problem with this?
+1. This would be great--a unittest that could be run against the solr example
would be spectacular!
Also, on some of your comments:
- list comprehensions solely to perform looped execution are harder to parse
and slower than explicitly writing a for loop
List comprehensions seem to be a matter of contention for some. However, it's
a battle I'm not interested in fighting, so changed it to a for loop.
It is not a matter of contention for me for use in creating a list, but ISTM
less clear and less efficient if the purpose is _solely_ to perform a loop:
$ python -m timeit '[i+i for i in xrange(1)]'
100 loops, best of 3: 1.95 msec per loop
$ python -m timeit 'for i in xrange(1): i+i'
100 loops, best of 3: 1.38 msec per loop
- shadowing builtins is generally a bad idea
Any shadowing of builtins was unintentional. Did you see specific examples? I
run the code through pychecker and pylint to try to avoid such cases.
`id` is shadowed in a few places.
- all NamedList's appearing in the output are converted to dicts--this loses
information (in particular, it will be unnecessarily hard for the user to use
highlighting/debug data). Using the python/json response format would prevent
this. Not returning highlight/debug data in the standard response format (and
yet providing said parameters in the query() method) seems odd. Am I missing
something? Oh, they are set as dynamic attributes of Response, I see.
Definitely needs documentation.
Yes, this needs to be documented. (Please c.f. to my question about allowing a
complete directory structure.)
- passing fields='' to query() will return all fields, when the desired return
is likely no fields
I've changed the default for fields= to be '*', instead of None or . This
way, passing in 'fields=' will result in 'fl=' being passed to the backend.
However, I still don't see the point, as passing both 'fl=' and 'fl=*' return
the exact same set of fields (i.e., all) on my test setup.
Hmm, what if you pass fields='', score=True? Ideally tha would pass fl=score
to the backend, bypassing all stored fields.
- it might be better to settle on an api that permits doc/field boosts. How
about using a tuple as the field name in the field dict?
conn.add_many([{'id': 1, ('field2', 2.33): usome text}])
doc boosts could be handled by optionally providing the fielddict as a
(fielddict, boost) tuple.
I agree. I was not aware of field boosts at the time. I'll code this change.
Unfortunately, it is still somewhat awkward. In my python client I end up
passing (name, value, field boost or None) everywhere, but that clutters
up the api considerably.
It might be worth taking a look at the ruby client to see what Eric's done for
the api.
- for 2.5+, a cool addition might be:
if sys.version 2.5
import contextlib def batched(solrconn):
solrconn.begin_batch()
yield solrconn
solrconn.end_batch()
batched = contextlib.contextmanager(batched)
Use as:
with batched(solrconn):
solrconn.add(...)
solrconn.add(...)
solrconn.add(...)
Adding...
Unfortunately, it does push the required python version to 2.4. Personally, I
think that requiring 2.4 is not unreasonable, but I'm somewhat of a bleeding
edge guy...
[incidently, it would be best to keep comments in JIRA, for posterity]
Improvements to solr.py
---
Key: SOLR-216
URL: https://issues.apache.org/jira/browse/SOLR-216
Project: Solr
Issue Type: Improvement
Components: clients - python
Affects Versions: 1.2
Reporter: Jason Cater
Assignee: Mike Klaas
Priority: Trivial
Attachments: solr.py
I've taken the original solr.py code and extended it to include higher-level
functions.
* Requires python 2.3+
* Supports SSL (https://) schema
* Conforms (mostly) to PEP 8 -- the Python Style Guide
* Provides a high-level results object with implicit data type conversion
* Supports batching of
Re: Commented: (SOLR-216) Improvements to solr.py
[reposting to solr-dev as JIRA destroyed my quoting...]
On 29-May-07, at 12:41 PM, Jason Cater wrote:
I've had my solr.py in production use internally for about a month
now. So, as you can imagine, I've worked through a few oddball bugs
that occasionally pop up. It seems pretty stable for me.
Yes, I agree that it is looking good. Since we would be replacing
the existing implementation completely, I think that it is worth
taking extra care and examining the api choices carefully so we won't
have to replace it or deprecate things in the near future.
I would prefer to have a complete directory structure (i.e.,
setup.py, unit tests, samples, etc) instead of just the solr.py
file. Would anyone see a problem with this?
+1. This would be great--a unittest that could be run against the
solr example would be spectacular!
Also, on some of your comments:
- list comprehensions solely to perform looped execution are
harder to parse and slower than explicitly writing a for loop
List comprehensions seem to be a matter of contention for some.
However, it's a battle I'm not interested in fighting, so changed
it to a for loop.
It is not a matter of contention for me for use in creating a list,
but ISTM less clear and less efficient if the purpose is _solely_ to
perform a loop:
$ python -m timeit '[i+i for i in xrange(1)]'
100 loops, best of 3: 1.95 msec per loop
$ python -m timeit 'for i in xrange(1): i+i'
100 loops, best of 3: 1.38 msec per loop
- shadowing builtins is generally a bad idea
Any shadowing of builtins was unintentional. Did you see specific
examples? I run the code through pychecker and pylint to try to
avoid such cases.
`id` is shadowed in a few places.
- all NamedList's appearing in the output are converted to dicts--
this loses information (in particular, it will be unnecessarily
hard for the user to use highlighting/debug data). Using the
python/json response format would prevent this. Not returning
highlight/debug data in the standard response format (and yet
providing said parameters in the query() method) seems odd. Am I
missing something? Oh, they are set as dynamic attributes of
Response, I see. Definitely needs documentation.
Yes, this needs to be documented. (Please c.f. to my question
about allowing a complete directory structure.)
- passing fields='' to query() will return all fields, when the
desired return is likely no fields
I've changed the default for fields= to be '*', instead of None or
. This way, passing in 'fields=' will result in 'fl=' being
passed to the backend. However, I still don't see the point, as
passing both 'fl=' and 'fl=*' return the exact same set of fields
(i.e., all) on my test setup.
Hmm, what if you pass fields='', score=True? Ideally tha would pass
fl=score to the backend, bypassing all stored fields.
- it might be better to settle on an api that permits doc/field
boosts. How about using a tuple as the field name in the field dict?
conn.add_many([{'id': 1, ('field2', 2.33): usome text}])
doc boosts could be handled by optionally providing the fielddict
as a (fielddict, boost) tuple.
I agree. I was not aware of field boosts at the time. I'll code
this change.
Unfortunately, it is still somewhat awkward. In my python client I
end up passing (name, value, field boost or None) everywhere,
but that clutters up the api considerably.
It might be worth taking a look at the ruby client to see what Eric's
done for the api.
- for 2.5+, a cool addition might be:
if sys.version 2.5
import contextlib def batched(solrconn):
solrconn.begin_batch()
yield solrconn
solrconn.end_batch()
batched = contextlib.contextmanager(batched)
Use as:
with batched(solrconn):
solrconn.add(...)
solrconn.add(...)
solrconn.add(...)
Adding...
Unfortunately, it does push the required python version to 2.4.
Personally, I think that requiring 2.4 is not unreasonable, but I'm
somewhat of a bleeding edge guy...
-Mike
[jira] Commented: (SOLR-215) Multiple Solr Cores
[ https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499919 ] Otis Gospodnetic commented on SOLR-215: --- Henri - I'm starting to ook at this. I see a lot of space changes in the patch. Could you please generate a patch that doesn't have all those space changes? When you generate a diff file for the patch, these may be handy parameters to use (I'm assuming you're going work under some kind of UNIX) -E --ignore-tab-expansion Ignore changes due to tab expansion. -b --ignore-space-change Ignore changes in the amount of white space. -w --ignore-all-space Ignore all white space. -B --ignore-blank-lines Ignore changes whose lines are all blank. Thanks! I just skimmed the patch and didn't see where the name of the index/core gets passed in the request. Can you please point me to the right place to look? Multiple Solr Cores --- Key: SOLR-215 URL: https://issues.apache.org/jira/browse/SOLR-215 Project: Solr Issue Type: Improvement Reporter: Henri Biestro Priority: Minor Attachments: solr-trunk-533775.patch, solr-trunk-538091.patch, solr-trunk-src.patch Allow multiple cores in one web-application (or one class-loader): This allows to have multiple cores created from different config schema in the same application. The side effect is that this also allows different indexes. Implementation notes for the patch: The patch allows to have multiple 'named' cores in the same application. The current single core behavior has been retained - the core named 'null' - but code could not be kept 100% compatible. (In particular, Solrconfig.config is gone; SolrCore.getCore() is still here though). A few classes were only existing as singletons and have thus been refactored. The Config class feature-set has been narrowed to class loading relative to the installation (lib) directory; The SolrConfig class feature-set has evolved towards the 'solr config' part, caching frequently accessed parameters; The IndexSchema class uses a SolrConfig instance; there are a few parameters in the configuration that pertain to indexing that were needed. The SolrCore is built from a SolrConfig an IndexSchema. The creation of a core has become: //create a configuration SolrConfig config = SolrConfig.createConfiguration(solrconfig.xml); //create a schema IndexSchema schema = new IndexSchema(config, schema0.xml); //create a core from the 2 other. SolrCore core = new SolrCore(core0, /path/to/index, config, schema); //Accessing a core: SolrCore core = SolrCore.getCore(core0); There are few other changes mainly related to passing through constructors the SolrCore/SolrConfig used. Some background on the 'whys': http://www.nabble.com/Multiple-Solr-Cores-tf3608399.html#a10082201 http://www.nabble.com/Embedding-Solr-vs-Lucene%2C-multiple-Solr-cores--tf3572324.html#a9981355 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-216) Improvements to solr.py
[ https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499922 ] Mike Klaas commented on SOLR-216: - I just noticed that I changed my own python query code to POST from GET two months ago, but I can't remember why at the moment. It is possibly due to url length limitations (occasionally I was passing a lot of data in the query args), but that doesn't seem quite right now. Changing to GET makes sense to me (though rapid updates are still a potential problem--perhaps it would be worth recommending against persistent connections on linux). Improvements to solr.py --- Key: SOLR-216 URL: https://issues.apache.org/jira/browse/SOLR-216 Project: Solr Issue Type: Improvement Components: clients - python Affects Versions: 1.2 Reporter: Jason Cater Assignee: Mike Klaas Priority: Trivial Attachments: solr.py I've taken the original solr.py code and extended it to include higher-level functions. * Requires python 2.3+ * Supports SSL (https://) schema * Conforms (mostly) to PEP 8 -- the Python Style Guide * Provides a high-level results object with implicit data type conversion * Supports batching of update commands -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-216) Improvements to solr.py
[ https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499923 ] Walter Underwood commented on SOLR-216: --- GET is the right semantic for a query, since it doesn't change the resource. It also allows HTTP caching. If Solr has URL length limits, that's a bug. Improvements to solr.py --- Key: SOLR-216 URL: https://issues.apache.org/jira/browse/SOLR-216 Project: Solr Issue Type: Improvement Components: clients - python Affects Versions: 1.2 Reporter: Jason Cater Assignee: Mike Klaas Priority: Trivial Attachments: solr.py I've taken the original solr.py code and extended it to include higher-level functions. * Requires python 2.3+ * Supports SSL (https://) schema * Conforms (mostly) to PEP 8 -- the Python Style Guide * Provides a high-level results object with implicit data type conversion * Supports batching of update commands -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-249) deprecate SolrException( int, ... ) in favor of SolrException( enum, ... )
[ https://issues.apache.org/jira/browse/SOLR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499939 ] Otis Gospodnetic commented on SOLR-249: --- Looks good to me after UNAVALIABLE - UNAVAILABLE deprecate SolrException( int, ... ) in favor of SolrException( enum, ... ) -- Key: SOLR-249 URL: https://issues.apache.org/jira/browse/SOLR-249 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Priority: Minor Attachments: SOLR-249-EnumErrorCode.patch SolrException should return valid HTTP status codes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-249) deprecate SolrException( int, ... ) in favor of SolrException( enum, ... )
[ https://issues.apache.org/jira/browse/SOLR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-249: --- Attachment: SOLR-249-EnumErrorCode.patch oh spelling... deprecate SolrException( int, ... ) in favor of SolrException( enum, ... ) -- Key: SOLR-249 URL: https://issues.apache.org/jira/browse/SOLR-249 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Priority: Minor Attachments: SOLR-249-EnumErrorCode.patch, SOLR-249-EnumErrorCode.patch SolrException should return valid HTTP status codes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-249) deprecate SolrException( int, ... ) in favor of SolrException( enum, ... )
[ https://issues.apache.org/jira/browse/SOLR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499945 ] Yonik Seeley commented on SOLR-249: --- +1 for committing deprecate SolrException( int, ... ) in favor of SolrException( enum, ... ) -- Key: SOLR-249 URL: https://issues.apache.org/jira/browse/SOLR-249 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Priority: Minor Attachments: SOLR-249-EnumErrorCode.patch, SOLR-249-EnumErrorCode.patch SolrException should return valid HTTP status codes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-249) deprecate SolrException( int, ... ) in favor of SolrException( enum, ... )
[ https://issues.apache.org/jira/browse/SOLR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-249. Resolution: Fixed Fix Version/s: 1.2 deprecate SolrException( int, ... ) in favor of SolrException( enum, ... ) -- Key: SOLR-249 URL: https://issues.apache.org/jira/browse/SOLR-249 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Priority: Minor Fix For: 1.2 Attachments: SOLR-249-EnumErrorCode.patch, SOLR-249-EnumErrorCode.patch SolrException should return valid HTTP status codes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Stedman updated SOLR-84: -- Attachment: sslogo-solr-flare.jpg New Solr logo? -- Key: SOLR-84 URL: https://issues.apache.org/jira/browse/SOLR-84 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, solr-nick.gif, solr.jpg, solr.jpg, sslogo-solr-flare.jpg, sslogo-solr.jpg, sslogo-solr.jpg Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) sarraux-dessous.ch) has reworked his logo proposal to be more solar. This can either be the start of a logo contest, or if people like it we could adopt it. The gradients can make it a bit hard to integrate, not sure if this is really a problem. WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Stedman updated SOLR-84: -- Attachment: sslogo-solr2.jpg Here's yet another variation [sslogo-solr2] (BTW, disregard the black background version of sslogo-solr; I tried to paste a PNG that had a transparent background). New Solr logo? -- Key: SOLR-84 URL: https://issues.apache.org/jira/browse/SOLR-84 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, solr-nick.gif, solr.jpg, solr.jpg, sslogo-solr-flare.jpg, sslogo-solr.jpg, sslogo-solr.jpg, sslogo-solr2-flare.jpg, sslogo-solr2.jpg Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) sarraux-dessous.ch) has reworked his logo proposal to be more solar. This can either be the start of a logo contest, or if people like it we could adopt it. The gradients can make it a bit hard to integrate, not sure if this is really a problem. WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Stedman updated SOLR-84: -- Attachment: sslogo-solr2-flare.jpg New Solr logo? -- Key: SOLR-84 URL: https://issues.apache.org/jira/browse/SOLR-84 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, solr-nick.gif, solr.jpg, solr.jpg, sslogo-solr-flare.jpg, sslogo-solr.jpg, sslogo-solr.jpg, sslogo-solr2-flare.jpg, sslogo-solr2.jpg Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) sarraux-dessous.ch) has reworked his logo proposal to be more solar. This can either be the start of a logo contest, or if people like it we could adopt it. The gradients can make it a bit hard to integrate, not sure if this is really a problem. WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500024 ] Otis Gospodnetic commented on SOLR-84: -- I still like #7 the best. #10's ( sslogo-solr-flare.jpg ) flame is cool, though FLARE part would have to be removed, so there is no confusion with Solr flare stuff that Erik Co. have been working on. New Solr logo? -- Key: SOLR-84 URL: https://issues.apache.org/jira/browse/SOLR-84 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, solr-nick.gif, solr.jpg, solr.jpg, sslogo-solr-flare.jpg, sslogo-solr.jpg, sslogo-solr.jpg, sslogo-solr2-flare.jpg, sslogo-solr2.jpg Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) sarraux-dessous.ch) has reworked his logo proposal to be more solar. This can either be the start of a logo contest, or if people like it we could adopt it. The gradients can make it a bit hard to integrate, not sure if this is really a problem. WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500025 ] Ryan McKinley commented on SOLR-84: --- I like #10 I asked Juan (#3) to take another look... results are interesting, but I'm not sure how useful: http://lapnap.net/solr/ -- perhaps (f)? Nick (#7) is going to take another shot at something more professional as that seemed to be what people did not like about it. Hope it's not too late to sneak in some more ideas Not at all! Keep em coming! I don't think we should rush to get this out with solr 1.2... New Solr logo? -- Key: SOLR-84 URL: https://issues.apache.org/jira/browse/SOLR-84 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, solr-nick.gif, solr.jpg, solr.jpg, sslogo-solr-flare.jpg, sslogo-solr.jpg, sslogo-solr.jpg, sslogo-solr2-flare.jpg, sslogo-solr2.jpg Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) sarraux-dessous.ch) has reworked his logo proposal to be more solar. This can either be the start of a logo contest, or if people like it we could adopt it. The gradients can make it a bit hard to integrate, not sure if this is really a problem. WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-84: -- Attachment: (was: solr.jpg) New Solr logo? -- Key: SOLR-84 URL: https://issues.apache.org/jira/browse/SOLR-84 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, solr-nick.gif, solr.jpg, sslogo-solr-flare.jpg, sslogo-solr.jpg, sslogo-solr2-flare.jpg, sslogo-solr2.jpg Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) sarraux-dessous.ch) has reworked his logo proposal to be more solar. This can either be the start of a logo contest, or if people like it we could adopt it. The gradients can make it a bit hard to integrate, not sure if this is really a problem. WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-84: -- Attachment: (was: sslogo-solr.jpg) New Solr logo? -- Key: SOLR-84 URL: https://issues.apache.org/jira/browse/SOLR-84 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, solr-nick.gif, solr.jpg, sslogo-solr-flare.jpg, sslogo-solr.jpg, sslogo-solr2-flare.jpg, sslogo-solr2.jpg Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) sarraux-dessous.ch) has reworked his logo proposal to be more solar. This can either be the start of a logo contest, or if people like it we could adopt it. The gradients can make it a bit hard to integrate, not sure if this is really a problem. WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ready for release 1.2
: everything looks good license-wise to me. I forgot LICENSE.txt has info on all the licenses involved (i thought that was just suppose to be ASL and the dependency licenses were all listed in NOTICES.txt) LICENSE.txt still refers to Jetty 5.1, and the new easymock info has no newlines. -Hoss
[jira] Commented: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500030 ] Ryan McKinley commented on SOLR-84: --- Oops, deleting files renames the numbering - the #7 that Otis and I pointed to in the above comments is now #8. New Solr logo? -- Key: SOLR-84 URL: https://issues.apache.org/jira/browse/SOLR-84 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-f.jpg, solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, solr-nick.gif, solr.jpg, sslogo-solr-flare.jpg, sslogo-solr.jpg, sslogo-solr2-flare.jpg, sslogo-solr2.jpg Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) sarraux-dessous.ch) has reworked his logo proposal to be more solar. This can either be the start of a logo contest, or if people like it we could adopt it. The gradients can make it a bit hard to integrate, not sure if this is really a problem. WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ready for release 1.2
Chris Hostetter wrote: : everything looks good license-wise to me. I forgot LICENSE.txt has info on all the licenses involved (i thought that was just suppose to be ASL and the dependency licenses were all listed in NOTICES.txt) LICENSE.txt still refers to Jetty 5.1, updated in rev 542755 The licenses pointed to in 5.1 no longer exist -- it looks like they are now using their own implementation or bundling it under the same apache license now - - example/etc/LICENSE.javax.servlet.txt - - example/etc/LICENSE.javax.xml.html - - example/etc/LICENSE.jsse.txt and the new easymock info has no newlines. added
Re: ready for release 1.2
On 5/30/07, Ryan McKinley [EMAIL PROTECTED] wrote: Chris Hostetter wrote: : everything looks good license-wise to me. I forgot LICENSE.txt has info on all the licenses involved (i thought that was just suppose to be ASL and the dependency licenses were all listed in NOTICES.txt) LICENSE.txt still refers to Jetty 5.1, updated in rev 542755 The licenses pointed to in 5.1 no longer exist -- it looks like they are now using their own implementation or bundling it under the same apache license now - - example/etc/LICENSE.javax.servlet.txt - - example/etc/LICENSE.javax.xml.html - - example/etc/LICENSE.jsse.txt We actually don't need to mention anything for Jetty in LICENSE.txt if it's all under the ASL2.0 But what about the CDDL license? I think we probably need their NOTICE file though (copy it into ours). According to the ASL 2.0: (d) If the Work includes a NOTICE text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. -Yonik
